Add flag for exiting with status 0 even in the presence of errors about gometalinter HOT 6 CLOSED

In the situation you describe, what do you imagine would result in a non-zero exit status?

I don't think adding a flag is necessary, but exiting with a different status code might achieve what you want?

from gometalinter.

I am not intimately familiar with the code base so I can't give the most precise suggestions. However, I could envision a few cases where it would still exit with a non-zero exit code:

• Cannot write to stdout
• One of the linters failed to run or the command did not exist
• Specifying an invalid command line invocation (passing a flag that does not exist etc)
• Linters timing out

There are probably more. I would prefer a flag over having two different exit codes because in Go it is quite painful to get at the actual code. It is also OS-specific so it makes it harder to write portable programs if you have to distinguish between e.g. exit code 1 and 2. It can be done and is still preferable to no solution, but I would personally prefer the flag. Up to you though :)

from gometalinter.

Hey, any thoughts on this?

from gometalinter.

I think I understand what you're trying to achieve now. Currently, timeouts, missing linters, linter failures, etc. are logged but do not result in a non-zero exit status. You'd like to know that all the linters are running correctly to completion.

This seems reasonable to me.

I'd be happy with a flag like --strict that causes gometalinter to exit with a status code > 1 if any of the above issues occur. I don't like the idea of exiting with a zero status for linter failures, as this directly goes against expected behaviour. And for all practical platforms, an exit code shouldn't be an issue.

from gometalinter.

It turns out that this was more difficult than anticipated, but the new code removes the reliance on cmd/sh which is also a good thing.

from gometalinter.

Great, thank you for this! The solution you implemented will work nicely for me. And yes, it seems that getting the exit status is more portable than before (I believe windows did not implement syscall.WaitStatus before), so that will be fine. Thanks again!

from gometalinter.