This is a compelling notion to me. I'd prefer an implementation where the default was generic and the use-case was specific; ie have the complier return 1's for compilation errors/other, and have specific CLI use-cases extend the semantics, like mix test returning 2 for test failures.
On Tuesday, July 13, 2021 at 1:13:37 PM UTC-7 jonar...@gmail.com wrote: > In our CI environment, we run our tests with this command: > > mix test --warnings-as-errors <files> > > This is intended to fail when someone has created a warning within a test > file in addition to when the tests themselves fail. We have an earlier > check (MIX_ENV=test mix compile --force --warnings-as-errors) that > validates that our production code is warning-free, but this does not > compile nor validate test files. > > A few of our tests are somewhat finnicky, and will fail sporadically (e.g. > due to PostgreSQL deadlocks). So we also have retry logic in our CI > environment that will re-run tests when the above command exists > unsuccessfully (exit code != 0). However, no amount of re-running will fix > a compilation warning! Presently, both test failures *and* compilation > failures return exit code 1, and so we are not able to differentiate > between the two and only re-run in the former case. > > Would it be appropriate to change the compilation failure case to return > an exit code of, say, 2? > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/4d33bc53-017f-42f1-aa69-ceba1be8378cn%40googlegroups.com.
