I looked around for something to do this but couldn't find anything so I started working on a format that will allow for the structured packaging of a series of drush calls. These digestible calls can be chained together or reference each other to form a type of recipe much like chef does; just specific to drush.
Right now the PoC is a JSON array but the format and structure of this animal is up for debate. I'm looking for this to be generalizable and useful to as many systems as possible. This can be hooked into Jenkins / other control systems (since its drush) or executed as a stand alone call (again since its drush). Themes, modules, install profiles, drush plugins, drush home directory, and custom sites/all/drecipes/ (libraries style) are all valid locations for seeking out .drecipe formatted files.
A draft is in the following sandbox and is working. It provides two example .drecipe files that can be invoked to issue a series of calls against a site. The update status one is a simple one and the security hardening one is a more complex, go get modules as well as call the admin update recipe.
Feedback much appreciated: https://www.drupal.org/sandbox/btopro/2299951
Comments
Have you considered using bash scripts?
Or maybe exec'ing Drush from puppet or chef?
Yeah, I think 'a string of
Yeah, I think 'a string of drush commands' is probably best represented as bash scripts or Drush commands of their own.
I have a couple other thoughts, though they aren't related to drecipe directly.
re executable: plan is to
re executable: plan is to then hook the drush der --y command into a control system but this way I'm not going to be writing a ton of things specific to a control system only to find that Jenkins is now the new sauce vs puppet vs this client over here doesn't want to use those things or this client likes "dated way of doing this" type of thing. I'm hoping this can keep my commands generalized regardless of how they are invoked since it's making drush commands more readable (basically).
re string of drush commands: This is just personally; I'd trust a made up, unexecutable file format that's included with a module / theme someone is providing over a bash script. Again, preference I think. Instead of having a bash script hosting server, being able to serve up "our standard migration routine from dev to prod from a "chef server" but written entirely in drush is appealing.
I plan on plugging it into other package control systems more easily since it'll be drush invoking more complex drush; as well as automatic recording of database calls and converting them into .drecipe files (this is already there in a super dev form), and integrating with a form widget since I'm working on an AEgir-esk system.
Love the idea of the "drush server" btw :)
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
This now has a full release
This now has a full release node and a ton more work beyond this initial discussion -- check it out! https://drupal.psu.edu/content/delicious-drush-desserts
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
In beta now and provided an
In beta now and provided an example of a bash script that we were able to crush the logic in thanks to drush recipes -- drush recipes cookin' up sweet beta eats! http://drupal.psu.edu/content/drush-recipes-cookin-sweet-beta-eats
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/