You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Drush deploy performs a config import and database update without providing the opportunity for interaction.
To Reproduce
Run drush deploy on any system that requires a database update and/or configuration update.
Expected behavior
I would have had the opportunity to answer "no" to any prompt that appeared and the process would stop.
Actual behavior
The system will display a prompt, but immediately continue. The user has not chance to provide input, and drush will continue, performing the updates/import.
Workaround
Yes - one can simply run the individual commands that deploy runs individually.
If you run drush adding a --no, it will fall out of the routine when it detects a db update/config change (and since it sees the subprocess as a failure, will spit blood).
System Configuration
Q
A
Drush version?
12.4.3/12.x-dev
Drupal version?
10.2.2
PHP version
8.1.26
OS?
Linux
Additional information
It seems there's no tty accessible to these sub-commands (as these seem to need to be enabled. I dug all the way through this, and there's nothing wrong with e.g. parameter handling/defaults/etc. - for example: Drush::affirmative was confirmed to return false throughout.
Things get right down to where a prompt is made, and it returns immediately upon trying to read a line from stdin (returning false).
I added a $process->setTty(true); to configureProcess (in drush/src/SiteAlias/ProcessManager.php). I'd have offered a PR, but I'm guessing this is not quite the appropriate way to handle this - perhaps this method needs to be optional? In any case, doing this at least provided me the ability to respond to the sub-commands.
--Perhaps TMI fold here--
I'm assuming my expectations match the intended behavior (have prompts be accessible). Kind of surprised not to see this as a documented bug in that case...perhaps not many are using the deploy command in their workflow?
Aside from my team's expectations, notes from #5228 seem to align:
Also, change the example in drush deploy --help to not use -y (and to remove and accept all prompts), since it implies that's not already the default behavior.
And the reply:
If you dont want avoid prompts and just accept defaults, run with --yes or --no-interaction.
Hope this helps, and thanks for the great work!
The text was updated successfully, but these errors were encountered:
Describe the bug
Drush deploy performs a config import and database update without providing the opportunity for interaction.
To Reproduce
Run
drush deploy
on any system that requires a database update and/or configuration update.Expected behavior
I would have had the opportunity to answer "no" to any prompt that appeared and the process would stop.
Actual behavior
The system will display a prompt, but immediately continue. The user has not chance to provide input, and drush will continue, performing the updates/import.
Workaround
Yes - one can simply run the individual commands that deploy runs individually.
If you run
drush
adding a--no
, it will fall out of the routine when it detects a db update/config change (and since it sees the subprocess as a failure, will spit blood).System Configuration
Additional information
It seems there's no tty accessible to these sub-commands (as these seem to need to be enabled. I dug all the way through this, and there's nothing wrong with e.g. parameter handling/defaults/etc. - for example: Drush::affirmative was confirmed to return false throughout.
Things get right down to where a prompt is made, and it returns immediately upon trying to read a line from stdin (returning
false
).I added a $process->setTty(true); to configureProcess (in
drush/src/SiteAlias/ProcessManager.php
). I'd have offered a PR, but I'm guessing this is not quite the appropriate way to handle this - perhaps this method needs to be optional? In any case, doing this at least provided me the ability to respond to the sub-commands.--Perhaps TMI fold here--
I'm assuming my expectations match the intended behavior (have prompts be accessible). Kind of surprised not to see this as a documented bug in that case...perhaps not many are using the deploy command in their workflow?
Aside from my team's expectations, notes from #5228 seem to align:
And the reply:
Hope this helps, and thanks for the great work!
The text was updated successfully, but these errors were encountered: