3 ms·

> The CI check is the important one: It's what ensures that bad formatting doesn't make it into master. I'd say that running linters in precommit hooks is the

by fivea 5y ago

> The CI check is the important one: It's what ensures that bad formatting doesn't make it into master. I'd say that running linters in precommit hooks is the ideal use case, as linters do not belong in CICD pipelines (i.e., it would make absolutely no sense to block a release just because a whitespace didn't matched an arbitrary rule) and linting stuff before committing also eliminates iterations in code reviews to handle inane stuff like where to break a line or how many spaces come before and after a bracket.

matharmin 5y ago
IMO linters definitely belong into the CI/CD pipeline. I do block a release if there are whitespace issues - it's trivial for the developer to fix, and part of basic code hygiene standards that we enforce in every repository. And if there is an emergency hotfix that needs to go out as soon as possible, we do have processes in place to bypass the CI/CD checks.
jen20 5y ago
That’s a pretty reductive attitude towards linters. If writing Go (for example), linters will tell you if you have ineffective assignments, or have neglected to check an error value - both things that may well block releases. While one could argue these are the job of the compiler, they are not today, and so linting during CI is not only appropriate, but practically required.
- fivea 5y ago
  > While one could argue these are the job of the compiler, they are not today, and so linting during CI is not only appropriate, but practically required. I disagree. Stylistic choices should not block a pipeline. It's impossible to argue in favour of blocking a release just because there's a whitespace in a place where it makes some random developer frown. The robustness principle also applies here. And no, build/critical errors are not the same as stylistic/linting errors.
  - jen20 5y ago
    Whether you check errors is a correctness issue, not a stylistic one.
- giovannibonetti 5y ago
  The fact that Go requires a linter to ensure errors are properly handled is a whole other topic
  - jen20 5y ago
    I don’t disagree there.

by fivea 5y ago

matharmin 5y ago

IMO linters definitely belong into the CI/CD pipeline. I do block a release if there are whitespace issues - it's trivial for the developer to fix, and part of basic code hygiene standards that we enforce in every repository. And if there is an emergency hotfix that needs to go out as soon as possible, we do have processes in place to bypass the CI/CD checks.

jen20 5y ago

That’s a pretty reductive attitude towards linters. If writing Go (for example), linters will tell you if you have ineffective assignments, or have neglected to check an error value - both things that may well block releases. While one could argue these are the job of the compiler, they are not today, and so linting during CI is not only appropriate, but practically required.

fivea 5y ago
> While one could argue these are the job of the compiler, they are not today, and so linting during CI is not only appropriate, but practically required. I disagree. Stylistic choices should not block a pipeline. It's impossible to argue in favour of blocking a release just because there's a whitespace in a place where it makes some random developer frown. The robustness principle also applies here. And no, build/critical errors are not the same as stylistic/linting errors.
- jen20 5y ago
  Whether you check errors is a correctness issue, not a stylistic one.
giovannibonetti 5y ago
The fact that Go requires a linter to ensure errors are properly handled is a whole other topic
- jen20 5y ago
  I don’t disagree there.