Contrib.social

Add Alpha level Experimental Automatic Updates module

Open on Drupal.org →
Created on 7 December 2021, over 2 years ago
Updated 19 May 2024, 30 days ago

Please DO NOT push to this branch. See How to Help for instructions for working in the contrib module.
The latest work for Automatic is happening in the Automatic Updates Contrib module → . There is conversion process but it is not being run constantly so the contrib module is the place for now to review the latest code see #30(should we just postpone?)

The latest work for Package Manager is happening in the Automatic Updates Contrib module → . There is conversion process but it is not being run constantly so the contrib module is the place for now to review the latest code see #37(should we just postpone?)

🌱 Drupal 10 Core Roadmap for Automatic Updates Active

Problem/Motivation

Automatic Updates is one of Drupal Core current strategic initiatives → . For full details of the initiative, see 🌱 Automatic Updates Initiative overview and roadmap Active .

Currently the work on the module is happening in 3.1.x branch of the Automatic Updates contrib module.

This issue is to bring in the current version of the 3.1.x branch of the contrib module into core as an Alpha level experimental module.

Proposed resolution

This merge request also includes the Package Manager module which it depends on from ✨ Add Alpha level Experimental Package Manager module Needs review

The merge request on this issue is created automatically from the 3.1.x branch of the contrib module.

Since this is will be a very large merge request we will continue to create issues and make improvements in the contrib module 3.1.x branch and convert that work via the conversion script to commits here. @tedbow or @phenaproxima will make the conversion daily if there are commits to the contrib module.

✨ Add Alpha level Experimental Package Manager module Needs review will have to be committed first, but this issue is open so that reviewers of that issue can see the Package Manager's API in use by Automatic Updates.

What does Automatic Updates do?

Package Manager does the underlying heavy lifting of automatic updates (that is, copying the codebase to a sandbox, making changes there, then bringing those changes back into the main codebase), but it provides no UI of its own. Package Manager has some basic restrictions about changes that can be made via Composer. For example it will check the at all Drupal extensions are secure and supported.

Here's what Automatic Updates itself does:

  • Provides a UI. It replaces the core Update module forms with a form that lists available updates and invokes Package Manager to kick off an update, assuming all the required preconditions are met. For example, a number of constraints are enforced here: are you on a stable release of core (you cannot update from a dev snapshot)? Is the filesystem writable? Once you start an update, Automatic Updates sets up a batch job for it, which calls Package Manager as needed to guide the user through the process. If a user updates in the UI, they also have the option to the next minor version of core (for example, from 10.1.3 to 10.2.0) -- although, for safety's sake, this functionality has to be enabled by a config flag.
  • Provides the ability to do updates in the background, unattended. They can either be kicked off by Automated Cron (or the /system/cron page), or by an additional crontab entry that calls a terminal command we supply, core/scripts/drupal. The benefit of this is security -- it allows the codebase to be modified by a different system user than whichever one the web server runs as. The trade-off is that it's more complicated to set up. Background updates are more tightly scoped than UI updates -- when doing a background update, you can only update to new patch releases in the same minor, since updating across minors is riskier. Background updates can also be configured to happen only if there's a new security update -- this is the default behavior, because we're assuming that your main goal, as a site maintainer, is to keep Drupal secure. Background updates will not update if the update needs database updates, though a email will be sent explaining this if happens.
  • If background updates fail, or cannot be started at all due to unfulfilled preconditions, Automatic Updates will notify the site owners by email. It will also notify the site owners when a background update is successfully completed.
  • One thing Automatic Updates doesn't do is update contrib modules and themes. There are some unresolved problems with this, and it's not in scope for the initiative. The functionality does exist in contrib, as the Automatic Updates Extensions module. (Currently this is a submodule of Automatic Updates, but will be a separate project in contrib once Automatic Updates is in core.)
  • Another caveat is that we don't allow background updates on Windows systems, because they have to be executed differently than on *nix environments. Since 🌱 [policy, no patch] Drop support for Windows in production Needs review we probably will never support background updates on Windows.

What can you update?

Automatic Updates only updates Drupal core in this first interation. It imposes many constraints on what versions of core you can update to and from. This isn't exhaustive, but here's the basic idea:

  • You cannot update if you are running a dev snapshot of core.
  • You cannot update to a different major version.
  • You can't downgrade. That is not a thing in Drupal.
  • You cannot update to a release of core that is unpublished, unsupported, or insecure.

Background updates have even more restrictions:

  • You must be running a stable version of core to do a background update. You cannot be running an alpha, beta, or RC.
  • You also have to be updating to a stable version of core. You can't update to an alpha, beta, or RC.
  • You cannot do a background update to a newer minor version of core; there is too much of a risk of things breaking without your knowledge.
  • You cannot do a background update to a version of core that has database updates. Because of the potential for serious breakage, you have to use the UI to do these sorts of updates. Unfortunately, this is something we can only detect while we're in the middle of the update (we statically analyze the incoming version of core to see if it has any database updates, and if it does, we delete the sandbox and fail with an error).

These rules are enforced by \Drupal\auto_updates\Validator\VersionPolicyValidator(). This is final class because we don't considered these rules an API.

How to test Automatic Updates

The easiest way to test Automatic Updates is to create a new Composer project from a slightly older version of Drupal. For example, composer create-project drupal/recommended-project:10.1.0.

You can then install Automatic Updates like any other module: composer require drupal/automatic_updates:^3@alpha. Since A

Once you install Drupal, go check for available updates. On the /admin/reports/updates/update, you should see an available update to Drupal 10.1.5 (or whatever is the current 10.1.x version when you test this), and a button to make it happen.

You can also test it at the command line by running vendor/bin/auto-update. By default, this will only update if the latest version of core is a security release; otherwise, it will say "no update available" and exit. To get around that, go to /admin/reports/updates/settings and "Unattended background updates" to "All patch releases". After that, running the auto-update command again should start an update to the latest version of core.

To test updating to the next minor version of core...create the project from Drupal 10.0.x (composer create-project drupal/recommended-project:~10.0.0), and install Drush. Once that's done, and you've installed Drupal, set a hidden config flag: drush cset automatic_updates.settings allow_core_minor_updates true. Then, when you visit /admin/reports/updates/update (you may need to force core to check for available updates first), you should see the option to update to the latest version of Drupal 10.1.x. Give it a try! (Note that the auto-update command will NEVER update across minor versions; it is strictly meant for updating between stable, patch-level releases in the same minor.)

How to help

Feel free to leave feedback on this merge request. If you would like to help address the feedback please search the 3.1.x issue queue → to see if any existing issue exists and if not create one in that project.

User interface


Update form showing update for current minor

Update form showing update for current and next minor

Downloading update

Update is staged, no database updates

Update is staged, with database updates

Applying updates

Status report, no problem

Status report, example problem

Config setting on Update module form

Remaining tasks

Core bugs

  1. 🐛 Exceptions in batch no longer are shown on the page when Javascript is disabled Needs work : affects our functional tests. We have a possible fix for that issue in this merge requests to allow our functional tests to pass. The only reason core tests are not currently failing in HEAD is because Core currently has no test coverage for how errors are shown on batch form

Core Policy Questions

  1. 🌱 [policy, no patch] Decide if and when automatic updates should rely only on packagist data to determine installability of modules Active
  1. Review the patch
  2. Framework manager sign-off
  3. Release manager sign-off
✨ Feature request
Status

Needs work

Version

11.0 🔥

Component
Update  →

Last updated about 1 hour ago

  • Maintained by
  • 🇺🇸United States @tedbow
  • 🇺🇸United States @dww
Created by

🇺🇸United States tedbow Ithaca, NY, USA

Live updates comments and jobs are added and updated live.
  • Needs framework manager review

    It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

  • Needs release manager review

    It is used to alert the release manager core committer(s) that an issue significantly affects the overall technical debt or release timeline of Drupal, and their signoff is needed. See the governance policy draft for more information.

  • Needs usability review

    Used to alert the usability topic maintainer(s) that an issue significantly affects (or has the potential to affect) the usability of Drupal, and their signoff is needed. When adding this tag, make it easy to review the issue. Make sure the issue summary describes the problem and the proposed solution. Screenshots usually help a lot! To get sign-off on issues with the "Needs usability review" tag, post about them in the #ux channel on Drupal Slack, and/or attend a UX meeting to demo the patch and get direct feedback from designers/UX folks/product management on next steps. If an issue represents a significant new feature, UI change, or change to the general "user experience" of Drupal, use Needs product manager review instead. See the scope of responsibilities for product managers.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024