Add a specific exit code when Drush finds security updates

[prudloff-insite]

Is your feature request related to a problem? Please describe.
Currently, Drush always returns 1 (EXIT_FAILURE) when a command fails.
This means that when running drush sec-php, our CI tool can not easily distinguish between a real error and available updates.

Describe the solution you'd like
It would be useful to have a specific exit code for available updates.

Describe alternatives you've considered
We can grep the error output but that is not very clean.

Additional context
The exit code is defined here:

drush/src/Commands/DrushCommands.php

Line 32 in cc3035f

const EXIT_FAILURE = 1;

And then used here:

drush/src/Commands/pm/SecurityUpdateCommands.php

Line 186 in cc3035f

return CommandResult::dataWithExitCode(new UnstructuredData($packages), self::EXIT_FAILURE);

[weitzman]

See #3749 for some related prior discussion. I don't think we will be changing this.

[prudloff-insite]

To clarify: I am not against drush sec returning a non-zero exit code (which seems to be what was discussed in #3749).
I am just suggesting returning a different non-zero exit code for available updates (like 2, for example).

[greg-1-anderson]

#3749 was about converting from returning a non-zero status code to returning a zero status code when there are updates. This is a request to change which status code Drush returns when there are security updates, so that scripts can distinguish between a failure state and a needs-update state.

As a general design point, I prefer commands to return no error when they work correctly. However, since Drush is already returning an error status in this case, I think it's better to maintain backwards compatibility and continue to return a non-zero update status when updates are needed.

Switching from a generic 1 (EXIT_FAILURE) to something more specific is, I think, reasonable, and wouldn't necessarily need to be called a breaking change. The big question is, which status code would we choose in this instance? It would have to be something between 3 and 125; also, 64-78 (and the region immediately after) should be avoided (see sysexits.h). There are not a lot of standards in this are.

[greg-1-anderson]

Status code 2 should be avoided, as it is one of the few codes that does have a defined meaning: misuse of bash built-ins.

[weitzman]

This sounds reasonable to PR. What number?

[greg-1-anderson]

3?