It looks like the `fix` goal does not exit with `1...
# general
It looks like the
goal does not exit with
in case it fixed something. Is this intended behaviour? The
goal does behave differently here. We have configured the following alias
Copy code
valid = "tailor --check fix lint check"
Which we also use in our CI pipeline. Since the
goal fixes everything before the
goal runs and it does not exit with
we did not notice some style issues on some of our PRs.
The lint goal runs all fixers/formatters to see if anything will change, so you only need
in CI
Yes I know, but for local development we automatically want to fix all issues. For consistency we want to use the same command in our CI pipeline as well.
The latter part sounds slightly nonsensical here. You want CI to edit files? I'd think you want it to confirm no edits are needed.
That basically sounds like the old hobgoblin quote - this is not an awesome blanket place for "consistency" to mean good.
Put it this way instead. If fix goal exited 1 - great for CI. But when a user runs the same command they get the wrong feedback! They should get 0 and all smiles, because letting fixers fix your code is good.
If you tell the dev 1, that trains them to pre-fix in their editor. They really shouldn't worry, they have fix after all; so the 1 for the devs is bad feedback I'd say.
So, in short, the two use cases are by their very nature inconsistent. Everything else follows.
(also ideally devs run
👍 1
hm, I see your point. The upstream packaged (black, isort, etc.) behave the same. I guess we did start doing it this way because we previously used pre-commit for the fixers which exited with code 1 if something was fixed. Thanks for the clarification!