Allow running `updb` and skipping maintenance mode

[mglaman]

Is your feature request related to a problem? Please describe. I do not want updb to put my Drupal site into maintenance mode

https://github.com/drush-ops/drush/blob/86f9205f7a8706847aaf8731d5967acb736f1bf9/src/Commands/core/UpdateDBCommands.php#L405C1-L409C10

        $original_maint_mode = \Drupal::service('state')->get('system.maintenance_mode');
        if (!$original_maint_mode) {
            \Drupal::service('state')->set('system.maintenance_mode', true);
            $operations[] = ['\Drush\Commands\core\UpdateDBCommands::restoreMaintMode', [false]];
        }

Describe the solution you'd like Just like cache-clear is an option, maintenance-mode should be one allowing --no-maintenance-mode

Describe alternatives you've considered I haven't found one, beyond trying to hack in with hooks

Additional context Just trying to have zero downtime deployments

[gitressa]

Nice catch @mglaman, I added a note on the https://www.drupal.org/docs/updating-drupal/updating-drupal-core-via-composer doc page:

3. Activate maintenance mode using drush state:set system.maintenance_mode 1 and then drush cache:rebuild. (Note: updatedb activates maintenance mode.)

[weitzman]

I'm curious how folks plan to achieve zero downtime deployments.

For starters, I think we can agree that only some deployments are safe to run without maint mode. So an org would need to evaluate each deployment and run different commands accordingly. Would this be a human decision or a programmatic decision? Its not easy to decide - the set of update functions, post update, hook_deploy, config import, etc. that get run depends on the state of the target. So local might run dfferent functions from dev which might differ from stage which might differ from prod.

I"m not opposed to the proposal, I'm just skeptical that it will be used.

[mglaman]

So an org would need to evaluate each deployment and run different commands accordingly.

Exactly this. It'd very high touch.

Would this be a human decision or a programmatic decision?

Very human.

We already have this:

  #[CLI\Hook(type: HookManager::PRE_COMMAND_HOOK, target: UpdateDBCommands::UPDATEDB)]
  public function disableUpdbCacheClear(CommandData $commandData): void {
    $commandData->input()->setOption('cache-clear', FALSE);
  }

I don't think drush deploy should allow opting out of maintenance mode. We also don't use hook_deploy. I don't know if dev/stage/prod considerations should effect not wanting to set the site in maintenance mode automatically.

[weitzman]

drush deploy doesn't actually set maint mode apart from thats already in updatedb.

dev/stage/prod consideration affects how widely used the proposed option would be. I resist adding seldom used options because their clutter makes commands slightly harder to learn and use. updatedb has been in wide usage for a decade and I dont recall many requests for this.

Would you consider altering that batch operation away? See https://github.com/drush-ops/drush/blob/635fce5f8223bae5c39495ee5709e993127ca413/includes/batch.inc#L105C5-L105C54. I havent tried it but seems like it would work. That could be a resolution while we consider this proposal

[mglaman]

Would you consider altering that batch operation away?

That 100% works for me. I wasn't sure and didn't really dive into how we could hijack the batch. My only concern is that now the code has to live in a module and not our Drush commands in the root level src of the project. But it's not the worst solution. We can work with that.