Hacker News Reader

Comment by matharmin | Hacker News Reader

The CI check is the important one: It's what ensures that bad formatting doesn't make it into master.

The pre-commit is just a convenience for the developer. It gives faster feedback - immediately when trying to commit, instead of a couple of minutes later. And if a developer on my team wants to disable it, it doesn't affect others.

And yes, it's important that you use the same version in dev and on CI/CD. The same applies for practically any other tool you use in your project. I see the CI/CD config as the "master" version - it's a known-working setup, that any developer should be able to use.

View on HN

> 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.

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.

The fact that Go requires a linter to ensure errors are properly handled is a whole other topic

I don’t disagree there.

> 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.

Whether you check errors is a correctness issue, not a stylistic one.

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.

Reply on news.ycombinator.com