Run slack:deploy:starting after deploy:starting instead of before

[johnpray]

so that variables set during the starting phase with ask calls can be included in the starting message.

We needed this since some of our stages use ask :branch to get the git branch that should be deployed, which we wanted to be included in the deploy starting message in Slack. Without this change, trying to fetch :branch in the starting message would result in text like #Proc:0x007f33427b0670@config/deploy/staging.rb:15> (while it would appear fine in the finished and failure messages, since the branch had been provided by that point).

Despite the slight delay in when the starting message appears, I think this change is actually the desirable default behavior, since you probably don't want to broadcast a deploy is starting until any necessary variables have been asked for. An alternative could be to make it an option, which I didn't tackle here.

[johnpray]

Just updated the proper spec and rebased with that. Thanks, Travis CI, for reminding me.

[phallstrom]

Nice @LouieGeetoo . I've merged and pushed 0.0.11 to ruby gems.

I'd be curious to see the bit of your cap file where you use ask :branch. That might be handy for some things I've got going on as well.

[johnpray]

Thanks for the awesomely-quick merge and release!

Since we're often deploying feature branches for testing to our staging environments, we put this in our staging stage files (e.g. config/deploy/staging.rb) The proc makes it default to the current branch, but ask gives you a chance to type in a different one:

ask :branch, proc { `git rev-parse --abbrev-ref HEAD`.chomp }

and in our production stages, we just always set it to master (partially so we don't accidentally deploy a feature branch):

set :branch, "master"

[phallstrom]

Neat. I've been using this:

set :branch,         ENV.fetch('BRANCH', 'master')

And then invoke it with BRANCH=f_foo cap staging deploy

I think I like your solution better.