Hey,

This looks really nice. I'm just wondering how I'd go about deploying with this strategy to a clustered environment. Any ideas or is it intended for a single box?

Cheers
Daniel

I'm using RVM and gemsets for each app in production and I like giddyup (without the hat even),
but my stop hook wasn't running bundler ... it couldn't find it.
I am no *nix expert but It works when I place this at the top of my hook file:

!/bin/bash

export RAILS_ENV="production"
source "/usr/local/rvm/scripts/rvm"

... the "#!/bin/bash" seemed necessary for it to do "source ..." .

The git push output even reminds me of heroku.

I just thought this might someone else from googling.
Thanks for this.

Hi,

the giddyup script uses readlink, which has a different synopsis as under linux
current (linux):
HOOK="$(dirname $(readlink -f $0))/update-hook"

on mac os x:
HOOK="$(dirname $(readlink $0))/update-hook"

It currently just prints:

Deploying to environment 'production'
Completed deployment in 0.00 seconds.

it should also set the return code.

update-hook does not expand files under the start and stop directories; instead, it looks for hook files named start/* and stop/*.

Shell trace:

remote: + '[' -d /home/foo/deployment/releases/20120501-165952/config/hooks/stop ']'
remote: + for f in '"${RELEASE}/${HOOKDIR}/${hook}/*"'
remote: + exec_hook_file '/home/foo/deployment/releases/20120501-165952/config/hooks/stop/*'
remote: + local 'hook_file=/home/foo/deployment/releases/20120501-165952/config/hooks/stop/*'
remote: + '[' -x '/home/foo/deployment/releases/20120501-165952/config/hooks/stop/*' ']'
remote: + rm -f current

Giddyup could handle checking out and working with specific branches and tags.

The rationale behind that is simply that it would be easier to work with remote locations/servers if they were attached not to the master (default) but to a specific tag, such as deploy or staging. This means pushing out staging to a production location would not result in any changes (preventing a possible disaster ;) )