18F/18f.gsa.gov — pull request #149 by konklone (2014-09-12 23:17:05+00:00)
Title: Refactor hooks to use tiny script that takes args on command line

Following up on the comments in https://github.com/18F/18f.gsa.gov/pull/145#issuecomment-55461666, I think it's better to use a much smaller, less hacky script to do the webhooks. This way, staging/production/development-specific params can be given over the command line instead of being hardcoded. This is also more suitable for porting to other projects.

It's too bad that [`hookshot`'s CLI](https://github.com/coreh/hookshot#cli-tool-1) doesn't have a daemonize flag of some sort, so instead, I'm using `hookshot` as a JS module and taking advantage of [`forever`](https://github.com/nodejitsu/forever)'s simple daemonization.

The plan here is to run **two** webhooks, listening on two different ports. Both will receive all pushes, but each will only pay attention to a single branch. nginx will route requests to the right port based on the hostname the hook uses to reach the box.

The staging hook will be at `https://staging.foia.us/deploy` and will be run at port `3000` using this command:

```bash
forever start -l $HOME/hookshot.log -a deploy/hookshot.js -p 3000 -b staging -c "cd $HOME/staging/current && git pull && jekyll build >> $HOME/hookshot.log"
```

The production hook will be at `https://18f.gsa.gov/deploy` and will be run at port `4000` using this command:

```bash
forever start -l $HOME/hookshot.log -a deploy/hookshot.js -p 4000 -b production -c "cd $HOME/production/current && git pull && jekyll build >> $HOME/hookshot.log"
```

I've tested this in development (it's easier than it was in #145) but it's still really only possible for me to verify this in production after merging, so I'm going to go ahead and do that.