Log explanation of non-zero exit with found results

[bill-rich]

Using exit code 1 is causing confusion because the overseer reports that the child process exited with 1 when debug logging is enabled.

Our options are:

• Change the exit code to some other non-zero code. This would convey it is a non-general error, but would still be non-zero.
• Exit with 0 when results are found. Using zero would break cases where finding results should count as a failure, such as CI.
• Add a debug message explaining why a non-zero code is returned. This should clear up most confusion, but could still be unclear if trufflehog is run by building and running since 'go run' will display the exit code even if debug is not enabled.
• Add debug message and use non-zero code.

I've opted for the last option to make sure the reason for a non-zero exit is clear. 183 was picked because Windows system code 183 means "Already exists", which could loosely be applied as erroring because the results exist.

[mcastorina]

Hm.. what do you think of using a flag to control the exit code on found results (like curl --fail)? We could use a similar flag --fail which will have a non-zero exit code when results are found.

Without the flag, 0 means successfully ran (with or without found secrets), and non-zero means there was an error.

With the flag 0 means successfully ran with no found secrets, 1 means error during scan, and 183 (or another number) means scan ran successfully and found secrets.

[dustin-decker]

I think it would be ideal if we did two additional things:

1. Add a --fail flag like @mcastorina suggested. We'd also update the github action to include this flag.
2. Update our overseer fork to suppress failure logging for exit code 183

It's technically a breaking change but I don't think we need to cut v4 just yet 😅
Similar with the json output improvements we'll make soon.

[bill-rich]

I like the --fail plan. That way we keep the ability to use it in CI, but it also clears up all this confusion.

@dustin-decker @mcastorina What do you think of removing the first warning that is based on the error returned for exit code errors, and making the 2nd debug only. That way, running with --fail will exit with 183, but no output about it (because there is no stderr output). --fail --debug will have a message about the exit code, but right next to an entry about why it is returning 183, Just --debug alone will still show the code (0 or otherwise).

[mcastorina]

Nit: a note here saying 183 only happens with the --fail flag would be good.

[bill-rich]

Good idea. Fixed.