Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Discussion workflow we wondered why not wrap drush pm-update
into a task?
We first need to define what to update.
Drupal is a platform update
Site is a site update
But sites/all/* is what? Is drush capable see the difference between a sites/*/* and sites/all/*?
Let's first check for the drush workflow.
Comments
Comment #1
helmo CreditAttribution: helmo commentedFor Git supported sites this should work together with #2273495: Push/commit support
Comment #2
ergonlogicThis would only make sense in a site context, as we don't have the ability to backup platforms, and so wouldn't have a reasonable rollback mechanism.
sites/all
is part of the platform, so we'd need to look at whether Drush supports only updating the modules in a specific site.Comment #3
ergonlogicI just took a look at the docs for
pm-updatecode
. While it provides the ability to exclude core, it doesn't have any capability to differentiate modules installed at a site-specific level, versus those insites/all
. I'm pretty sure that we are tracking these in the Aegir front-end, in thehosting_package_instances
table, when theplatform
field is set to -1, iirc.So, I suppose we could do something like the following:
drush @site_alias dl
for eachupdatedb