Continuous Integration Spring Cleaning

Continuous Integration is a fancy term for “run your project’s tests after someone pushes to the repository and notify interested parties if they fail.”

We’re currently in the process of revamping our test suite (which we’ll blog about in the future) and moving servers, so I thought it’d be a good time to re-evaluate our options.

img http://img.skitch.com/20090806-u2d8ww3qytifhkxm7kaberrsm.png http://integrityapp.com

Integrity has grown a lot since its first release. It has a ton of features, great documentation, and nice notifiers (I wrote the Campfire notifier).

It also has a very attractive interface, is easy to configure, and works with multiple projects. And it’ll run anything – not just Ruby projects.

It’s not the easiest thing to install, though. There are a lot of dependencies and I never quite got it working on my latest install attempt. I hear it works better with Passenger.

If you can get it working, it’s worth it. qrush’s report card is a great addition, too.

img http://img.skitch.com/20090806-rjt63ut1pni3j38y32644uh3i1.png http://buildbot.net/trac

BuildBot is a Python builder that’s pretty feature complete. And, of course, it works great with GitHub.

I installed it and tried it out – it’s pretty easy to use. And because it’s a generic builder you can also use it for non-test related tasks, like compiling stuff. It has a server BuildBot and worker BuildBots which means you can scale it to run many concurrent tasks, even across machines.

For us it seemed overpowered, but I’ll definitely keep it in mind if we need hardcore lifting in the future.

img http://img.skitch.com/20090806-mqxp7ep62h3rwudqt2u1f272rr.png http://runcoderun.com

RunCodeRun is Relevance’s hosted CI service. It supports both private and open source projects, but is Ruby-specific.

For an example check out the AASM project overview or a specific build view. Pretty nice. It has tight GitHub integration, too, linking to each commit.

Unfortunately RCR doesn’t support Campfire notifications yet, as far as I can tell. We need ’em!

CI Joe

Because knowing is half the battle. CI Joe is a dead simple, Git-talkin’, Unix-lovin’, HTTP slingin’ continuous integration server we wrote to do one thing and do it well.

img http://img.skitch.com/20090806-ryw34ksi5ixnrdwxcptqy28iy7.png http://github.com/defunkt/cijoe

It uses your Git config and lets you extend it through Git hooks. A POST will trigger a build – which means it works great with GitHub. It supports HTTP auth so Internet prankster can’t trigger your builds. It comes with Campfire support. It’s language agnostic – as long as your test suite can be run from a Unix shell, CI Joe can handle it.

img http://img.skitch.com/20090806-f7j3r65yecaq13hdcxqwtc5krd.png http://github.com/defunkt/cijoe

Check out the documentation for the complete tour.

We use the Campfire notifier (I sound like a broken record, don’t I) and Joe’s HTTP basic auth feature. Our config looks like this:

$ cat .git/config
...
[campfire]
  user = notifier@github.com
  pass = secret
  subdomain = github
  room = The GitHub Dancy Party
[cijoe]
  user = chris
  pass = secret
  runner = rake -s test:units

We also use Joe’s “after-reset” hook. We keep our database.yml file in Git, but the CI server needs its own database config settings. If Joe finds an executable “after-reset” Git hook it’ll run it after updating the repo and before running the tests. Ours looks like this:

$ cat .git/hooks/after-reset
rm config/database.yml
cp database.yml config/database.yml

As you can see, we keep our good database.yml unversioned in the CI clone’s root and just remove the versioned one after each reset. Joe runs a “git reset –hard” which does not remove unversioned files – our custom database.yml won’t get wiped.

Again, check out the source and documentation to get rollin’. Issues go to Issues or the mailing list.

Enjoy.