Garuda - automated deployment
and git post-receive hook script runner
Who can benefit from Garuda?
Anybody who deploys several websites and applications to several servers stand to benefit the most. But anybody who hosts git repositories remotely will also find Garuda to be helpful.
What is Garuda?
When a user pushes to a remote git repository, Garuda manages which scripts you'd like to run and which environment variables you'd like to be available. All of this is defined in a config file for the repository.
A config example file
# config/awesome_site.yml heads: develop: deploy/rsync: source: htdocs/ destination: firstname.lastname@example.org:/home/user/dev/htdocs tags: # Matches 1.2.2-RC1, 2.12.1-RC2 etc. '^[0-9]+.[0-9]+.[0-9]+-RC[0-9]+$' deploy/rsync: source: htdocs/ destination: email@example.com:/home/user/staging/htdocs # Matches 1.2.2, 2.12.1, etc. '^[0-9]+.[0-9]+.[0-9]+$': rename: rename: 'htaccess.production .htaccess' deploy/ftp: source: htdocs destination: ./user/production/htdocs host: 184.108.40.206 user: joe pass: shcmoe
Gitosis / Gitolite setups
- Add garuda to your conf file, then clone it locally
- Navigate to the home directory of your gitosis / gitolite user on your server
Run this in the terminal (on the server as the git user, otherwise use sudo)
ruby -e "$(curl -fsS https://github.com/rpflorence/garuda/raw/master/install/gito.rb)"
If you used
sudoin step 3, change the ownership to your gitolite / gitosis user (here it's git, use whatever yours is)
sudo chown -R git garuda
- Navigate to the directory on your server where you want to install
Run this in the terminal
ruby -e "$(curl -fsS https://github.com/rpflorence/garuda/raw/master/install/simple.rb)"
- Write scripts that do stuff and put them in
- Use the
lib/directory for scripts that require extra logic (
bin/scripts should rarely do more than a couple of lines.)
bin/scripts must be executable
chmod +x bin/file
# config/awesome_site.yml heads: develop: 'deploy/rsync': source: 'htdocs/' destination: 'firstname.lastname@example.org:/home/user/site/htdocs' tags: '^[0-9]+.[0-9]+.[0-9]+$': rename: rename: 'htaccess.production .htaccess' 'deploy/ftp': source: 'htdocs' destination: './public_html' server: 220.127.116.11 user: joe pass: shcmoe
If a user pushes a branch like this:
$ git push origin develop, on the server, Garuda will:
- Check out the
developbranch of the repository
- Set two environment variables:
- And finally run the
If a user instead pushes a tag like this:
$git push origin 2.1.3, then Garuda will check out the tag 2.1.3, because it matches the regex yaml key under
tags, set the environment variables and call each script.
It always checks for a regex match. So pushing branches like "develop" and "develop-topic" both match
/develop/, and, in this case, would both execute the
deploy/rsync script. This can be prevented with a stricter key like
^develop$, which would be an exact match for a branch named "develop".
Though YAML provides a number of data types, environment variables can only be strings, so keep it to key:value pairs. If you need more than that, you'll need to parse the string in your bin script like any good shell script does.