CRM-11457 drush civicrm-upgrade-db fails with no errors

So I believe the Upgrade page is no longer appropriate for drush use. There is a comment in r40216 which explains what should be happening.

To illustrate, CRM_Upgrade_Page_Upgrade has logic like this:
$action = CRM_Utils_Array::value('action', $_REQUEST, 'intro');
... and functionality is split up by action: intro, begin, finish.

Methinks that the intention was for drush to call CRM_Upgrade_Headless instead.

For the record, this hideous invocation seems to work perfectly: drush eval 'civicrm_initialize(); $up = new CRM_Upgrade_Headless(); $up->run(true);'

trunk (r44193) has the CRM_Upgrade_Headless code, but it falls back to CRM_Upgrade_Page_Upgrade. I believe this code path should be removed. & in 4.2.6, drush is totally hosed.

This is interesting – I can't reproduce in my environment, and (FWIW) I've used "drush civicrm-upgrade-db" as part of my daily workflow throughout the 4.2.x lifecycle. A few thoughts:

• Have you tested what happens when removing/disabling the fallback? I'm not sure how it would fix things – it only uses the fallback if it fails to find the CRM_Upgrade_Headless class. If it can't find the "Headless" class, then going straight to calling CRM_Upgrade_Headless should fail, too, right?

• Does it make a difference if you add these lines to the civicrm.settings.php:

require_once 'CRM/Core/ClassLoader.php';
CRM_Core_ClassLoader::singleton()->register();

• The fallback is there so that one copy of civicrm.drush.inc can work with multiple versions of CiviCRM. This is useful in a multisite/Aegir deployment where different sites may be independently upgraded to different versions.

• Instead of removing the test

if (class_exists('CRM_Upgrade_Headless'))

you might try changing it to something that doesn't depend on the class-loader:

global $civicrm_root;
if ( file_exists("$civicrm_root/CRM/Upgrade/Headless.php"))

• If it's still unresolved, let me know more about the environment, e.g.
  + Drupal version
  + Drush version
  + Site layout – eg single site ("sites/default/civicrm.settings.php") or multisite ("sites/example.com/civicrm.settings.php")
  + PHP version (5.3.x, 5.2.x, 5.4.x) and build (Debian, MAMP, etc)

• For reference, I'm testing drush upgrade with the following configurations:
  + System A: Drupal 7.12, CiviCRM 4.2.x (branches/v4.2), multi-site (with combined Drupal+CiviCRM DBs), PHP 5.3.3 from Debian
  + System B: Drupal 7.18, CiviCRM 4.3.x (trunk), single-site (with split Drupal+CiviCRM DBs), PHP 5.4.4 from MAMP

Hi, thanks for taking a look at this.

I think i see where the confusion is coming from. The 4.2.6-drupal6 tarball contains an unknown revision of civicrm.drush.inc, which does not reference Headless. Looking under /tags/tarballs/4.2.6/drupal/drush/civicrm.drush.inc, I see that the correct revision is r43370, which does contain the Headless code. I wonder what else was merged incorrectly...

The second issue here is the fallback code – but looking at the revision history, you cleanly added Headless and introduced the 3-phase web ui both in r40216, so you're right that it's safe to leave this code as-is to support multiple site versions.

That makes sense. The build-process for the Drupal 6 tarball is a bit wonky – it gets most of the code from /branches/v4.2, but the "drupal" directory comes from "branches/v3.4/drupal".

FWIW, this command shows a lot of other changes that haven't made it into the D6 version of drush.inc:

svn diff http://svn.civicrm.org/civicrm/branches/

/drupal/drush/civicrm.drush.inc

Could you try copying the newer civicrm.drush.inc to your D6 site to see how well it works?

I tried copying the newer drush script and it went great. I haven't tested any code paths other than civicrm-upgrade-db, however.

Thanks for the explanation, I was suspecting something was fishy about the drupal6 release. Soon enough it won't matter... but drupal/ should probably be a submodule, or "extern" whatever it's called in svn.

I've copied the civicrm.drush.inc used for D7 so that it will also be used for D6 (r44239).

This fix doesn't seem to have actually made it into the 4.2-drupal6 branch, as this is still a problem in 4.2 for D6. Now that 4.2 is in LTS support, is this ticket the place to address that, or is there a better place?