Problem/Motivation

#3087214: Expose manual method to update site does a good job of bindly letting someone just click a link to update their site until they reach the end of their minor version updates. Its logic is intentionally dumb and simple. Let's do things more better and figure out what is the most recent next minor version to which we wish to upgrade.

Steps to test

  • Prerequisite: Have an install of Drupal 8 that needs an update. Bonus, install a version that has known security issues.
  • Install module via composer, composer require drupal/automatic_updates
  • Apply patch.
  • Visit /admin/config/automatic_updates, expand the experimental section, read the dire warnings and hit that link.

Note, depending on what version you are updating from, #3087196: Handle HTTP Status 429 from quasi patch files has not landed so you might have to hit that link a couple times to actually be successful.

CommentFileSizeAuthor
#10 3087463-10.patch15.12 KBheddn
#10 interdiff_9-10.txt1.87 KBheddn
#9 interdiff_2-9.txt12.12 KBheddn
#9 3087463-9.patch15.35 KBheddn
#2 3087463.patch2.77 KBheddn

Comments

heddn created an issue. See original summary.

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented
Status: Active » Needs review
StatusFileSize
new 3087463.patch2.77 KB

This expands upon #3087214: Expose manual method to update site to provide a link to the recommended version, without as much dumbness.

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented
Issue summary: View changes
heddn’s picture

heddn
Primary language English
Location Nicaragua
commented
Issue summary: View changes
ressa’s picture

ressa
he/him
commented

Cool, with this improvement I get to go directly from 8.7.4 to 8.7.8:
http://autoupdate.lndo.site/automatic_updates/in-place-update/drupal/cor...

I do get these warnings, the update succeeds nevertheless. Perhaps I get them because I use Composer, and not the tarball?:

Warning message

Your site does not pass some readiness checks for automatic updates. Depending on the nature of the failures, it might effect the eligibility for automatic updates.
The project "Automatic Updates" can not be updated because its version is either undefined or a dev release.
The hash for INSTALL.txt does not match its original. Updates that include that file will fail and require manual intervention.
The hash for README.txt does not match its original. Updates that include that file will fail and require manual intervention.
The hash for autoload.php does not match its original. Updates that include that file will fail and require manual intervention.
The hash for composer.json does not match its original. Updates that include that file will fail and require manual intervention.
The hash for composer.lock does not match its original. Updates that include that file will fail and require manual intervention.
The hash for example.gitignore does not match its original. Updates that include that file will fail and require manual intervention.
The hash for modules/README.txt does not match its original. Updates that include that file will fail and require manual intervention.
The hash for profiles/README.txt does not match its original. Updates that include that file will fail and require manual intervention.
The hash for sites/README.txt does not match its original. Updates that include that file will fail and require manual intervention.
The hash for themes/README.txt does not match its original. Updates that include that file will fail and require manual intervention.

After updating, initially this text is shown:

No update for Drupal is available for version 8.7.4.

After I run drush cr, I get the correct text:

No update for Drupal is available for version 8.7.8.

So perhaps the cache can be rebuilt by the module, after the update process is completed?

Also, great to see that changed files are now getting logged, thanks! However, since there are so many insertions now, would it be possible to list the files in a single log insertion, or would that become too large?

----------------------
Putting my process for creating a fresh Lando environment here, to document it for myself, but also if others are interested, It takes me around two minutes:

# get older version 8.7.4 of Drupal core to test updating directly to 8.7.8 (8.7.5 is a security update)
git clone git@github.com:drupal-composer/drupal-project autoupdate
cd autoupdate/
sed -i 's|\^8.7.0|8.7.4|g' composer.json

# create fresh Lando instance
lando init --recipe drupal8 --webroot web --name autoupdate
lando start

# get Drupal core files and install
composer update --with-dependencies --no-dev -v
drush site-install --db-url=mysql://drupal8:drupal8@database/drupal8 --account-pass=content -y

# get modules and enable
composer require --update-no-dev drupal/admin_toolbar drupal/automatic_updates:1.x-dev
drush en admin_toolbar admin_toolbar_tools automatic_updates -y

# test the patch in "Leverage update.xml to discover core security updates"
cd web/modules/contrib/automatic_updates/
wget https://www.drupal.org/files/issues/2019-10-11/3087463.patch
patch -p1 < 3087463.patch
cd -

# rebuild cache and get login link
drush cr
drush uli -l http://autoupdate.lndo.site

# shut down and destroy Lando instance when done, and remove the directory
lando stop
lando destroy
chmod 775 web/sites/default
cd ..
 rm autoupdate -rf
heddn’s picture

heddn
Primary language English
Location Nicaragua
commented
Related issues: +#3087501: How much and how to log when updating in-place

I've opened #3087501: How much and how to log when updating in-place to address the logging concerns.

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented
Status: Needs review » Needs work

NW for clearing cache + code standards.

line 142 A comma should follow the last multiline array item. Found: 'Note: Might break the site. No readiness checks or anything in place. Just update the files of Drupal core. Database updates are not run.'

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented

Those warnings/errors come from readiness checks. The manual update process is very manual and doesn't honour anything. It in a sense bypasses any and all safety net. But it lets us get valuable feedback while we are experimenting. Please keep the input coming.

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented
Status: Needs work » Needs review
StatusFileSize
new 3087463-9.patch15.35 KB
new interdiff_2-9.txt12.12 KB

Here we add some guard rails to the mix. For example 8.7.2 adds a modification to composer.lock. That is a modified file and with the current nature of how this module depends on 3rd party php dependencies, it means we have a modified composer.lock file.

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented
StatusFileSize
new interdiff_9-10.txt1.87 KB
new 3087463-10.patch15.12 KB

Fixing phpcs.

  • heddn committed 6bd17e0 on 8.x-1.x 
    Issue #3087463 by heddn, ressa: Leverage update.xml to discover core...
heddn’s picture

heddn
Primary language English
Location Nicaragua
commented
Status: Needs review » Fixed

I couldn't reproduce the issue w/ caching of the version string. If it surfaces again, we can fix it w/ a bug fix. This is an improvement over no guardrails, so committing.

ressa’s picture

ressa
he/him
commented

I also now can't reproduce the version string thing @heddn. After updating it works perfectly, and shows the correct text:

No update for Drupal is available for version 8.7.8.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.