Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Provide quasi-patch package on ftp.drupal.org of updates from one point release to another. See #3055872: In place updates (from quasi-patch zip), which has the format for the quasi-patch.
Proposed resolution
Remaining tasks
- ✅ Create a DB table to track quasi-patch status, with columns
from_release_nid,to_release_nid, timerequested, timegenerated,errorif not generated, intermediate keyexpiration. - ✅ Add
in-place-updatesmenu callback as a fallback for files that have not been generated. It will validate the request, return a “try again soon” response, add a row to the quasi-patch status table, add to a queue. - ✅ Resolve https://github.com/drupal/php-signify/issues/13, so intermediate key expiration can be stored.
- ✅ Set up a queue runner to generate the quasi-patches.
- ✅ Set up cron to remove files nearing their intermediate key expiration date.
- ✅ Add integrity checking to monitor for errors.
Comments
Comment #2
drummTo start, I think I’ll only generate these for sequential patch versions. If someone skips from 1.2.3 to 1.2.5, nothing is stopping them from going back and releasing 1.2.4, for example.
Comment #4
drummThese updates are now available as examples:
They include a
checksumlist.csigfile signed with the temporary keys.The autoupdates client should plan on requests potentially failing, ideally retrying maybe 3 or 4 times, with maybe 20 seconds between requests. I realized that dong the version number math of what the “incremental” change would be would be hard to get right, with plenty of edge cases. As this moves closer to production, I plan to have the initial request go to a queue, and respond immediately that it is being worked on. Once the processing for the item completes, it is just a static file that will be served quickly and cached.
Comment #5
drummAdding notes on queue architecture to the issue summary.
Comment #6
drummComment #8
drummThe files in #4 have all been regenerated with the top-level directory in the .zip files removed for easier processing by the client.
Comment #12
drummThe menu callback to handle in-place-updates that have not been generated yet, and associated tracking, is now deployed.
Requesting arbitrary update combinations like https://www.drupal.org/in-place-updates/drupal/drupal-8.7.4-to-8.7.7.zip will now be recorded, and respond with an HTTP 429 and a
Retry-After: 10header.Currently queue processing is not set up, so these will not be generated until I run a drush command.
Comment #14
drummQueue processing for this is now all hooked up. Arbitrary requests to this API will serve in a production capacity, except for the signing being with test keys until #3076191: Build a signing oracle server & HSM infrastructure is done.
Comment #15
heddnNICE!!!
Comment #17
drummIntegrity checks are now in, just need clearing expired files now.
Comment #19
drummFiles that are expiring will now be deleted around 48h before they expire.
I think this resolves everything we need to resolve in this issue. The updates are still signed with a temporary key, until #3076191: Build a signing oracle server & HSM infrastructure is done.