Add a soft confirm option to drush updb #5806
Comments
|
Slight correction/addendum, it's not either a OR b. a) is always asked after listing the updates while b) is asked before the updates are listed. |
|
And this is an example why I didn't want to add requirements check to updatedb. Folks who care about this should run |
|
drush rq in its current from doesn't do the same thing. That command is hardcoded to runtime requirements. the update requirements are a specific requirements scope that only lists relevant problems for the upgrade, things like missing updates and incompatible modules, things that are critical for the success for updating your site. runtime problems are often fairly OK to ignore, especially on test/local environments, upgrade problems very much not. |
|
Good point. I suggest expanding rq so it can run eitther requirement type. |
Drush requires the -y flag to run in automated environments because it prompts with the list of available updates. However it also does an update requirements check which gets skipped by the same -y option. This means that our update path in the CI doesn't fail if there are requirements errors (even though it should, because it causes errors later in tests that are hard to debug) and our tests against fixture dumps for specific update scenarios also don't fail. Until Drush provides a better solution in drush-ops/drush#5806. We manually go through the update output and errors if the key sentence for requirements errors is spotted.
Drush requires the -y flag to run in automated environments because it prompts with the list of available updates. However it also does an update requirements check which gets skipped by the same -y option. This means that our update path in the CI doesn't fail if there are requirements errors (even though it should, because it causes errors later in tests that are hard to debug) and our tests against fixture dumps for specific update scenarios also don't fail. Until Drush provides a better solution in drush-ops/drush#5806. We manually go through the update output and errors if the key sentence for requirements errors is spotted.
Drush requires the -y flag to run in automated environments because it prompts with the list of available updates. However it also does an update requirements check which gets skipped by the same -y option. This means that our update path in the CI doesn't fail if there are requirements errors (even though it should, because it causes errors later in tests that are hard to debug) and our tests against fixture dumps for specific update scenarios also don't fail. Until Drush provides a better solution in drush-ops/drush#5806. We manually go through the update output and errors if the key sentence for requirements errors is spotted.
Is your feature request related to a problem? Please describe.
Drush updb has two very different confirmation messages
a) Everything is good to go, here are the update functions I'll run, should I?
b) There are requirement errors that will likely break your site if you proceed, are you sure?
drush updb -y says yes to both of them. Automated deployments both need -y atm but should in most cases not proceed in case b)
Describe the solution you'd like
Add something like a soft confirm that only confirms a) but not b in this scenario. Not sure how to name it. --yes-if-no-errors or something? or --no-(ok)-confirm(-without-errors)?
Describe alternatives you've considered
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: