Following some issues to integrate drush and making civicrm upgrade process accessible from script, I started looking at drush on how we can take advantage of it for civicrm, and was surprised with the ease I was able to reuse drush code to add few utilities for civicrm. Some of the utilities currently implemented are: 
All civicrm-sql-* utilities reuse the drush code, making most of drupal sql-* utilities also available for civicrm. Update-cfg and upgrade-* methods use civicrm BAOs to do their job. A detailed help can be seen just as any other "drush help $command" - 
For a quick view of how upgrade works with the script - 
As you would have noticed currently it requires --tarfile option, an improved version could be, automatically downloading the latest tarfile when no option is provided. Another related improvment i can think of is adding civicrm-restore utility which would restore the codebase and database to the specified restore point. So a command to restore would look like: drush civicrm-restore --restore-point=/var/www/drupal-6.16/../backup/modules/20100308134039 Another set of commands like civicrm-cache-clear and civicrm-api will soon make there way in. Check http://wiki.civicrm.org/confluence/display/CRMDOC/Drush+CiviCRM+proof+of+concept for more details (thanks to Kasper Souren). Since the initialization process is already in, it would now be easier to experiment and add new utilities to the list (and submit patches). If you have already done any work on civicrm-drush, and would like to share / contribute, let me know. civicrm.drush.inc file for now is part of the Drupal repository. To avoid any problems with the script during civicrm-upgrade keep the latest copy of civicrm.drush.inc out of codebase since process involves removing (after backup) and adding codebase. I always keep it in my .drush folder. Check example.drush.inc for other options.
How to start
For those who are not familiar with drush or don't know where to start - 1. Install and read about drush from http://drupal.org/project/drush. 2. Screencasts on above link should make you even more comfortable. 3. Download / checkout civicrm.drush.inc file from svn - https://github.com/civicrm/civicrm-drupal/blob/7.x-master/drush/civicrm.drush.inc 4. Place civicrm.drush.inc file inside your ~/.drush directory. And you are ready to play.
Comments
was hoping someone would get this figured out. nice work!
Re: drush_civicrm project - might not, since we license using AGPL 3 and is not valid under drupal's cvs plus we like to keep one copy in our own svn.
Will experiment with civicrm-download if time permits.
Not sure what you mean by civicrm-provision. But do consider submitting any work you would do.
thanks
This is wonderful! So much time will be saved working with and setting up new sites! Thank You!!
As to the licensing issues - the rules should safeguard your work but not get in the way. As a CiviCRM Team member, are you required to contribute everything back to CiviCRM? Could you and or others maintain/co-maintain something in Drupal Contrib that depends on Civi but is licensed compatibly with Drupal/drush?
Maybe drush people could be happy to put drush civicrm stuff directly into the main code base? That way drush civicrm becomes completely independent from any installation, just like drush itself.
I just created an issue at drupal.org in order to involve experienced drushers: add drush civicrm to drush?
we are working with the FSF in cleaning up various licensing aspects of CiviCRM. I dont think i'm in favor of dual licensing parts of the code base. We ship a lot of drupal integration code within CiviCRM (which is not dual licenses) and our drush integration can potentially follow the same model
lobo
If I understand correctly, this should fix one of the annoyances in Aegir: migrating a CiviCRM site between platforms (ex: to upgrade Drupal) would break the $civicrm_root in civicrm.settings.php.
However, by the looks of it, it will not change the directory paths which are stored in the domain information in the database. Any suggestions on how to tackle that issue? (I wish they would just be relative)
(To avoid deleting the domain entry, I usually symlink the old path to the new one, login to CiviCRM, change config, then remove the symlink.)
I look forward to testing this :)
matt/bgm
currently it expects a valid $civicrm_root in settings file. update-cfg takes care of correcting / fixing path settings in db.
Until this is packaged as a module, could you describe how to install ? Do we have to move civicrm.drush.inc to another location ?
For those leaving in the trunk side of things, would it handle incremental updates of the db ?
X+
Added a "How to start" section to make it more clear. And yes it would also handle incremental updates of the db. thanks
That's the default path used by drush too (for code backups). There is also a "--backup-dir" option which could be used.
But i also agree since it also includes sql backup. I'll make the default location to above drupal root directory.
Thanks.
Thanks, this is great news! Can't wait to play with it.
Thanks, folks, this is great!
Thanks, this is a super-helpful feature for drush, unfortuately it's not working for me.
I'm trying to update from CiviCRM 3.0 to 3.1.3 with this. Here's what I'm getting:
1. Code backed up.
WD php: parse_url(mysql://drupal:xxxxxx@127.0.0.1/civicrmtest?new_link=true): Unable to parse URL in /home/myuser/bin/drush-HEAD/includes/sitealias.inc on line 981. [error]
Fatal error: Unsupported operand types in /home/mindfulp/bin/drush-HEAD/includes/sitealias.inc on line 990 [error]
Drush command could not be completed.
This is with latest drush HEAD, but I get the same errors (with different line numbers) in the current supported drush release: All-versions-3.0-beta1.
I checked out civicrm.drush.inc from svn as instructed and put it in ~/.drush . Also, I was getting MySQL socket errors from drush until I changed 'localhost' to '127.0.0.1' in settings.php and civicrm.settings.php as indicated here: http://drupal.org/node/222611#comment-1987148 – that fixed the socket errors.
Any idea what's wrong? What version of drush did you do your tests with?
hey andy:
I dont think we've tested this on 3.0 beta as yet.
lobo
Sounds like a mysql connectivity issue. You should check if drush's sql utilities are working for your drupal install and narrow it down from there, since civicrm uses same code/api. There are various reasons why a mysql connection would fail. You might want to google on it (socket errors).
* Use forums for support questions please.
I checked out civicrm.drush.inc from svn as instructed and put it in ~/.drush .
since then i get this error message:
Fatal error: Cannot redeclare civicrm_install() (previously declared in /home/torstenzenk/.drush/civicrm.drush.inc:172) in /var/www/xxx/sites/all/modules/civicrm/drupal/civicrm.install on line 38
Drush command could not be completed.
what could that be?
I tried the civicrm-update-cfg command with CiviCRM 3.0.3 and got:
RECORD-dev3% drush -l http://stg.EXAMPLE.com/civicrm civicrm-update-cfg
PHP Fatal error: Call to undefined method CRM_Core_BAO_Setting::doSiteMove() in /usr/home/stg/.drush/civicrm.drush.inc on line 251
Fatal error: Call to undefined method CRM_Core_BAO_Setting::doSiteMove() in /usr/home/stg/.drush/civicrm.drush.inc on line 251
Drush command could not be completed. [error]
I copy/pasted http://svn.civicrm.org/civicrm/branches/v3.1/CRM/Core/BAO/Setting.php over on top of our existing file and this time it seemed to work great!
Only problem is it didn't seem to affect the customPHPPathDir and customTemplateDir variables; those are still pointed at the dev site.
I second (or third) the request to get this great code on d.o, or else make it part of CiviCRM core, so it's available to all. :)
I managed to debug this and found that the reason it wasn't working is the $dir variable in doSiteMove() is a bit too low-level. Patch uploaded upstream to add a $siteRoot directory, which fixes it for me: http://issues.civicrm.org/jira/browse/CRM-5862