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.

Proposed resolution

Remaining tasks

User interface changes

API changes

Comments

helmo’s picture

helmo commented

For Git supported sites this should work together with #2273495: Push/commit support

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
commented
Title: Add site / platform update task » Add site module/theme update task
Status: Active » Postponed (maintainer needs more info)

This 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.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
commented

I 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 in sites/all. I'm pretty sure that we are tracking these in the Aegir front-end, in the hosting_package_instances table, when the platform field is set to -1, iirc.

So, I suppose we could do something like the following:

  1. put the site in maintenance mode
  2. backup the site
  3. iterate over the site-specific modules, running drush @site_alias dl for each
  4. run updatedb
  5. take the site out of maintenance mode