wp-cli: RFC: Return with exit code 1 for some commands when an error occurs
Background
Some commands support performing the same operation against multiple resources (e.g. updating two or more plugins wp plugin update akismet hello). If one of the operations fails (e.g. a plugin can’t be installed), the command will display a warning, continue on, and exit with return code 0.
salty-wordpress ➜ wordpress-develop.dev wp plugin install foobar edit-flow akismet
Warning: Couldn't find 'foobar' in the WordPress.org plugin directory.
Warning: edit-flow: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the <a href="https://wordpress.org/support/">support forums</a>.
Warning: akismet: Plugin already installed.
salty-wordpress ➜ wordpress-develop.dev echo $?
0
There have been a few long-outstanding issues on this topic (#2002, #1430, #427). If we’re going to change the behavior, the time to change the behavior is before WP-CLI v1.0.0.
Proposal
For the commands that perform the same operation against multiple resources, WP-CLI will exit with return code 1 if one or more of the operations failed.
The affected commands include:
-
wp media (regenerate|import) -
wp menu delete -
wp menu item delete -
wp plugin (install|activate|update|toggle|deactivate|uninstall|delete) -
wp super-admin add -
wp theme (install|update) -
wp term delete -
wp widget (delete|deactivate|reset)
Rationale
For WP-CLI users who have integrated these commands into provisioning systems and other automation, return codes provide a helpful, machine-readable description of the results of the operation. Exiting with return code 1 will inform the system that some part of the operation has failed.
I’m most interested in feedback from WP-CLI users who have incorporated these commands into automated systems. If there are serious backwards compatibility concerns established, then we’ll keep the existing behavior and make sure it’s explicitly documented. Otherwise, the proposal will be accepted, we’ll change the behavior of the mentioned commands, and document the new behavior.
The decision on this proposal will be made on Tuesday, November 22nd.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 12
- Comments: 19 (11 by maintainers)
As someone who has this integrated into provisioning systems, I would much prefer the new behavior. If anything, this will improve our provisioning as we can better know when a failure happens and respond accordingly.
IMO even for interactive use of wp-cli, the exit code should return 1 or something non-zero if only 1 out of the 2 plugin installations succeeded in that scenario. That is a failure in my book because the operation being requested (install 2 plugins – not maybe_install 2 plugins) has failed.
Having visibility into which operation failed is important. If we are installing 10 plugins and the only thing we get back is a return code of 1, it would be helpful to have information about which of those operations failed (and maybe even which, if any, succeeded)? Perhaps that can be sent to stderr?
We chain commands at DreamHost, instead of an all in one, so that shouldn’t impact us except in places where we’re interactively running them (like a person would actually see the error). I’m triple checking to be sure though 😃
The latter. I’d change the behavior of each existing command.
WP_CLI::warning()won’t be changed; in fact, there are cases where we still want to display a warning without changing the return code.