Closed Ignigena closed 10 years ago
Seems legit. My only concern would be if someone was depending on that error exit.
@iamEAP any objections?
In this case, I wonder whether it would make sense to add a --strict
flag that defaults as TRUE
.
This way, existing behavior isn't changed and the error code will still be returned if others are relying on this in their workflow. However, it would allow the flexibility to disable strict mode and exit without an error code which would address my original motivation for this.
Thanks for the ping, @joshkoenig. No problems with the proposed change, from my perspective. Makes sense.
I think it's probably safe to implement generally. This is more "correct" in my opinion and I think it should be pretty easy for people to adapt to this change since it stops execution either way.
I am incorporating Terminus to allow for integration between a CI workflow and my Pantheon environment.
Currently, because of other things involved in the CI workflow, there are a number of builds happening that don't include changes to the Drupal docroot. In these cases, there are no code changes to the Pantheon environment which triggers the "No changes found to commit" message towards the end of the build process.
Since this message is being returned with
drush_set_error()
it is causing the deployment step to exit with an error code. This triggers a build failure even though the step is doing exactly what it should do and skipping over the commit process.I propose changing this to
drush_user_abort()
which will not exit with an error code but will continue to function exactly as it did previously and exit the process immediately once Terminus determines no changes are present.