Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deploy command does not allocate tty to subcommands, preventing interaction with dbup/cim #5855

Open
wolcen opened this issue Jan 25, 2024 · 1 comment

Comments

@wolcen
Copy link

wolcen commented Jan 25, 2024

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!

@weitzman
Copy link
Member

I wonder if tty defaulted to true in earlier versions of Synfony Console, at least for some configurations. We have had some trouble with this before consolidation/site-process#41 and consolidation/site-process#43

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants