Add environment lock/unlock/locked handling

[dblandin]

This PR adds support for deploy:lock and deploy:unlock tasks.

These tasks are intercepted and handled separate from any provider.

When an attempt to deploy to a locked environment is made, we'll send up an error deployment status with a description including who locked the environment.

Addresses #55

[atmos]

Looks pretty good. Can you run script/cibuild and fix the errors?

[atmos]

What's this stuff for?

[dblandin]

It's to prevent tests from messing with the default Heaven.redis instance. Here I'm switching to a different database number on localhost.

We could alternatively use something like fakeredis or mock_redis during testing.

[dblandin]

@atmos All set on the script/cibuild front. There's still a complexity warning for the main receiver #run! method but that'll take a bit more thought.

Maybe something like this would be more concise?

def run!
  unless receivers.detect { |receiver| receiver.new(event, guid, data).run! }
    Rails.logger.info "Unhandled event type, #{event}."
  end
end

private

def receivers
  [LockReceiver, DeploymentReceiver, DeploymentStatusReceiver, StatusReceiver]
end

Receivers that can't handle the event can return nil or false.

[atmos]

Can we use an environmental variable for this? like ENV['BOXEN_REDIS_URL'] || 'redis://localhost:6379'

[dblandin]

The main thing here is the /3 database number. 3 could really be any number beyond the default of 0. I don't see I way to extract the currently used redis url and tack on a different database number.

[dblandin]

Looks like we can do something like this instead:

config.around do |example|
  original = Heaven.redis.client.db
  Heaven.redis.select(3)
  example.run
  Heaven.redis.flushall
  Heaven.redis.select(original)
end

[dblandin]

We could use the last database index of 15 which I doubt anyone is going to use.

[atmos]

Yeah, let's try the redis select thing on 15 and see how everything is working.

[dblandin]

Just pushed up a commit. Seems fine on my machine.

[atmos]

Can you send another pr documenting the behavior of locking?

[atmos]

Maybe something like this would be more concise?

I just fixed it in something that reads a little easier than what you proprosed in 86fdcb6

[willdurand]

Hi! Commands deploy:lock or deploy:unlock are not intercepted, but forwarded to the deploy script (e.g. Fabric). Is there anything to do to "enable" these interceptors? (commands are sent using hubot-deploy from Slack)

[dblandin]

@willdurand Looks like the GitHub deployment webhook payload has changed since this feature was implemented. We'll have to update the mapping here. Happy to do that in a PR this week if someone doesn't get to it first.

Here's where you would find the current payload structure:

https://github.com/:owner/:repo/settings/hooks

[willdurand]

Thanks @dblandin, I created a PR (#170)