Add non-0 exit code on wp core check-update

[halfgaar]

I have wp-cli in cron jobs to check for updates. What's missing, is a non-0 return code when an update is available. I do a bunch of string matching now, but of course, that's not very robust.

Perhaps extra command-line flags would be the best, as not to break existing scripts.

And, there could be different return codes for major or minor upgrades, to script automatic minor updates, but notify on major, for instance.

[danielbachhuber]

Hi @halfgaar,

Thanks for the suggestion.

I'm undecided as to whether it's a good idea to make this change. At the very least, we'd need to make it a non-breaking change like you suggest. More so, I'm undecided as to whether it's a good idea to use exit codes to communicate whether or not an update is available.

My understanding of exit codes is that they're used to indicate error states. For instance, WP-CLI failing to execute as expected (e.g. database connection error) is a valid error state. It's unclear to me "has update" is a valid error state.

Could you describe your current implementation in greater detail, so we can better understand how you use the data?

Related wp-cli/doctor-command#125 (comment)

cc @davegaeddert

[davegaeddert]

The way I think about it is that each check is like a unit test and doctor is the testing framework (which could have it's own errors). So if one check returns an "error", then I expect the "test command" to fail. This is how pytest does exit codes, might be worth looking at other examples if that line of thinking makes sense: https://docs.pytest.org/en/latest/usage.html#possible-exit-codes

@halfgaar not sure how you're doing it right now, but one thing I've done in the meantime (if exit codes get merged in some way) is to get the output as JSON, parse that and use that status field. That's at least a little better than just searching for "error" in the table format or something.

[davegaeddert]

Sorry, just realized this wasn't on the doctor-command repo. Disregard anything I said that didn't make sense here...

[danielbachhuber]

Sorry, just realized this wasn't on the doctor-command repo. Disregard anything I said that didn't make sense here...

No worries, I think the same underlying principles apply.

[halfgaar]

Well, I currently do this in cron:

/usr/local/bin/wp core check-update | grep -Fiq success || echo "Example WP site update available"   | mail -s "Example Wordpress update available" me@example.com

Grepping on success is very flaky. The string output 'Success: WordPress is at the latest version.' is dubious anyway, because is it not a success when there is an update? When this string changes, my script will break.

Also, if wp does fail with an exit code now, the result it that I get an e-mail saying an update is available.

Hence the exit codes, to leave out the grep.

Return codes aren't necessarily failures. In bash, test -x textfile returns 1, so that you can write if [ -x textfile ]; then echo "blabla"; fi

I suppose one could use better parseable output, but there are still situations where that may break (translated output, for example).

[danielbachhuber]

We discussed this in Slack today. It doesn't make sense to change the exit code because the same goal can be achieved by using --format=count (which will either produce a zero or non-zero result).