Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When running remote commands regardless of what happens drush exits with 0. This means that errors can't be caught. Please ensure that drush remote actions return a non 0 value on error.
Here is some sample output from a jenkins job on a broken site:
drush @my-alias vset --always-set site_name test
PHP Fatal error: Call to undefined function entityreference_get_behavior_handlers() in /path/to/sites/all/modules/contrib/entityreference/entityreference.install on line 44
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Call to undefined function
entityreference_get_behavior_handlers() in
/path/to/sites/all/modules/contrib/entityreference/entityreference.install,
line 44
Finished: SUCCESS
Comment | File | Size | Author |
---|---|---|---|
#4 | set-result-code-for-remote.patch | 1.03 KB | greg.1.anderson |
Comments
Comment #1
nedjoRelated bug report on entityreference: #1459540: People seems to be able to disable a Field module which still has fields, and core seems to call field hooks on disabled modules.
Comment #2
greg.1.anderson CreditAttribution: greg.1.anderson commentedI don't think that #1 is related to #0, is it? I agree that it would be a good idea to fix #0.
Comment #3
nedjo#1 seems to be a source of the specific error reported in #0, so I added the reference in case people arrive here searching for that error. But, yes, the Drush return value is a distinct question, so this isn't a duplicate of #1459540.
Comment #4
greg.1.anderson CreditAttribution: greg.1.anderson commentedHere's a patch that could be committed to master + backported to 5.x. The mid-stream 'exit' is inelegant, but calling drush_set_error here causes problems with the Drush shutdown process, whereas this runs cleanly. Unit tests pass.
Perhaps we could commit this for now to get things working, and work on cleaning up bootstrap + error recovery in a follow-on issue later.
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commentedThis looks pretty inelegant. I'm OK with committing it, but lets please do that larger refactor soon.
Comment #6
greg.1.anderson CreditAttribution: greg.1.anderson commentedCommitted to master and 7.x-5.x. Will work out a better resolution for Drush-6, and leave Drush-5 as it is.
Comment #7
greg.1.anderson CreditAttribution: greg.1.anderson commentedc.f. Duplicate issue #1679920: drush user-add-role invalid_role gives exit code 0 when run remotely
Comment #9
webchickIt doesn't look like this was ever fixed for 6. Using latest bleeding-edge 8.x-6.x branch:
Yields:
Comment #10
webchickAlso closed #1828744: Drush fails to return unique exit code to shell in event of [warning] as a duplicate of this issue.
Comment #11
greg.1.anderson CreditAttribution: greg.1.anderson commented#9 is different than the closed issue, but can be tracked here. The new issue is that drush dl calls drush_log instead of drush_set_error when no release is found for a requested project.
Comment #12
greg.1.anderson CreditAttribution: greg.1.anderson commentedIn updatexml_get_release_history_xml():
So, we could fix this issue, but break pm-updatecode just by changing that drush_log to a drush_error. A more clever solution is needed. Perhaps updatexml_get_release_history_xml() could be changed to return a string in case of error, or an array of xml in case of no error. All of its clients would then need to call drush_log or drush_set_error as needed.
Assigning to myself so its not forgotten, but patches welcome if anyone else wants to pick this up.
Comment #13
Jon PughI seem to be having this problem on all commands that produce a drush error.... I still get 0 exit code when running an unknown command, for example:
Comment #14
greg.1.anderson CreditAttribution: greg.1.anderson commented#13 did not seem to be a problem for me on the latest master.
I fixed #12 not by adjusting the API call, but by calling drush_set_error explicitly in pm-download if fetching a release failed (and the failure is not due to a user abort).
Comment #15
greg.1.anderson CreditAttribution: greg.1.anderson commentedAlso pushed to 6.x.
Comment #16
greg.1.anderson CreditAttribution: greg.1.anderson commentedThis issue was marked
closed (won't fix)
because Drush has moved to Github.If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to
closed (duplicate)
.Please ask support questions on Drupal Answers.
Comment #16.0
greg.1.anderson CreditAttribution: greg.1.anderson commenteds/