It’s also often handy to configure linters and autoformatters as precommit hooks.
It’s also often handy to configure linters and autoformatters as precommit hooks.
Your CI pipeline is broken if it refuses to run because of style issues. Linting is either applied as a pre commit hook or manually by the developer. Anything else is a mistake you are making without any concrete tradeoff.
The same goes for other mistakes such as handling warnings as errors.
Imagine going into a meeting with a senior manager and explain that you cannot release a hot fix because your pipeline is broken due to the last commit having 5 spaces instead of 4.
And should I stress again that there is absolutely zero positive tradeoffs?
Just because you don't value or acknowledge them doesn't mean they don't exist.
As I specifically said, the CI should fail on the feature branch. If you’re only running CI on master, you’re going to run into the exact same problem if your unit tests fail. The way to avoid that problem is to run the unit tests on your feature branch, and if you’re doing that you might as well run the linters too.
Strong disagree. If it’s not in the CI, it’s optional. Respecting the formatting standards of the project is NOT optional.
It should definitely be applied as a pre-commit or pre-push hook too to make sure the CI step is just a formality, but it’s not enough.
The whole point of CI is to automatically verify the code. Linters are a method of doing that, the same as tests.
> Imagine going into a meeting with a senior manager and explain that you cannot release a hot fix because your pipeline is broken due to the last commit having 5 spaces instead of 4.
Sounds like an easy fix to me. And if your CI is set up properly, the misformatted branch wouldn’t have been merged to master in the first place.
Against errors and regressions. Meaning, stuff that breaks your code and affects the service you provide to users.
Style issues ain't that. Come on.