Support drush archive-dump

Great idea, i wanted to do this in 2.x, indeed. We should be backward compatible of course, but I think that's totally possible.

This will also allow us to import complete *platform* dumps too which is cool.

Subscribe.

sub

As mig5 suggested calling drush_invoke practically does it all.
I added a patch to demonstrate.

I tested this with the drush-7.x-4.x branch and provision 1.x(as the code is pretty much still the same between 1.x and 2.x)

The lack of a --no-core option should be fixable in drush. As I also would like see the opposite option, to backup a platform (e.g. before being deleted)

Obviously the restore part would have to be adapted as well..

I reckon that we need to get some tests written that test a site migration/clone before we can do any kind of major refactoring like this. Beginnings of that are here: #1267534: Factor out Jenkins tests into git

I've created an issue in the drush queue to request a --no-core option, and did some initial work in a sandbox.

#1277484: --no-core option for archive-dump

I'd love to work together on this, and could open the sandbox up for more committers...

I've had a look at the archive-restore part in drush.

And have come to the conclusion the provision would need much work to directly re-use the archive-restore command. I see conflicts with the OO approach provision has taken.

What we could do:
* detect the file format, (Aegir 1.x or archive-dump)
* interpret the MANIFEST.ini
* move files around

The todo's below could be a start to solving this...

--- platform/deploy.provision.inc
+++ platform/deploy.provision.inc
@@ -25,6 +25,8 @@ function drush_provision_drupal_provision_deploy_validate($backup_file = null) {
     ->status();
   if ($exists) {
     drush_set_option('backup_file', $backup_file);
+    // @TODO: This might be a good place to check if the backup file contains a MANIFEST.ini
+    // It's probaby wise to always extract to a temp dir, and the copy/move the wanted directories inplace
   }
 
   $exists = provision_file()->exists(d()->site_path)
@@ -52,6 +54,12 @@ function drush_provision_drupal_pre_provision_deploy($backup_file) {
     ->fail('Failed to extract the contents of @path to @target', 'PROVISION_BACKUP_EXTRACTION_FAILED')
     ->status();
   if ($extracted) {
+    
+    // @TODO: interpret the MANIFEST.ini
+    // $old might need to become something like: $temp_dir .'/web/' . $manifest[sitedir]
+    // A comment should make it clear that we are only using site specific data from the archive
+    // When an archive contains multiple sites: smart selection or just the first?
+    
     // Make sure the files in the files directory are accessible by the web server.
     provision_file()->chgrp(drush_get_option('extract_path') . '/files', d('@server_master')->web_group, TRUE)
       ->succeed('Changed group ownership of files in <code>@path&lt;/code> to @gid')
@@ -60,7 +68,8 @@ function drush_provision_drupal_pre_provision_deploy($backup_file) {
     if (drush_get_option('deploy_replace_site', FALSE)) {
       $old = d()->site_path . '.restore';
       $new = d()->site_path;
-
+      // @TODO: when we always use a temp dir to extract to... switch_paths should not depend on deploy_replace_site
+      
       $swapped = provision_file()->switch_paths($old, $new)
         ->succeed('Swapping out the @path1 and @path2 directories was successful.')
         ->fail('Swapping the @path1 and @path2 directories has failed.', 'DRUSH_PERM_ERROR')

I am *really* happy to see some progress here, keep up the good work!

I do think the --no-core option in drush is a good idea.

Also, keep in mind we need to be backward compatible with aegir 1.x here - so we'll need to interpret tarballs without a manifest as 1.x backups (ie. site only) when importing. I do not see, however, an issue with always generating drush-compatible, 2.x-style backups by default in 2.x...

Made some progress on this, but still going slow.

It would be nice if we could make this more pluggable...

e.g. to also support Hosting Drupal Gardens import and Hosting upload

Xref: #322788: generic import mechanism for external database dumps and site backups

Just re-rolled the patch from #11 to be able to work on it further...

New features need to be implemented in Aegir 3.x, then we can consider back-porting to Aegir 2.x.