I'd like to be able to run in-place updates on a site. To retain rollbacks, we can perform a site backup prior to running updates, and restore it in a rollback hook, if need be. To that end, I've written Hosting Update and Provision Update. These are sandbox projects at present, as @anarcat suggested they'd be good candidates for inclusion in core.
For a bit of background, these are the result of a discussion with @anarcat about a method of deploying changes to a site where the site directory is managed with Git, as part of Valkyrie. This task essentially provides a convenient (Drush) hook to allow a 'git pull'.
I'm working on a way to list the required updates in the confirmation form. However, this appears more complicated than everything that I've built so far for this. Basically, right now, I'm exploring implementing a 'provision-update-list' command. But, this has to be handled differently for various versions of Drupal, which would appear to best be done with an 'engine', etc.
A much simpler solution would be to patch Drush to add a '--list' option. This would allow us to use all Drush's complex logic, rather than have to re-implement it.
Comments
Comment #1
ergonlogicWith @helmo's encouragement, I've added this command/task to https://drupal.org/project/hosting_tasks_extra.
Comment #2
anarcat commentedi still believe this would belong in 3.x core, along with optimised migrate paths.
Comment #3
ergonlogicSo, there's a simple way to get this list of available updates from the command line:
drush updatedb --no. While it's not structured data, it's something we can work with. I've never tried passing the '--no' switch when invoking a Drush command programmatically though...The tougher problem seems to be that this'll need to run as the 'aegir' user on the backend, which entails queuing a task and retrieving its output before our confirmation form is displayed. The only example of something comparable, that I'm aware of, is with how hosting_remote_import gets a list of sites from the remote server via a batch callback.
Comment #4
ergonlogicI really wonder to what extent listing the updates is really required. I think it'd be a nice enhancement, but we're doing it blindly now.
Comment #5
anarcat commentedYeah, we don't need to list, let the user choose.
Comment #6
_vid commentedWould this help:
drush up --pipeThen you have a list to loop through.
Comment #7
ergonlogic@_vid unfortunately, no. We're talking about pending database updates after one or more modules have already been updated. Whereas the update module shows modules with more current versions available on d.o.
Comment #8
ergonlogicThis exists in contrib. We can merge it into a later version.
Comment #9
helmo commentedChanging status to finter it out of my regular issue list.
The more info can be read as needing a motivation to merge this as opposed to just using it from the hosting_tasks_extra module.
Comment #10
ergonlogicThis is actually in Aegir via Hosting Tasks Extra in Golden Contrib.