Setting up CIA: Continuous Integration Automater May 22nd

can thought of as a Rails-centric DamageControl engineered by David Heinemeier Hansson. It hooks into your Subversion repository and is called every time something is checked in. CIA checks out the full source tree into a temporary directory, successively runs all your unit and functional tests through `rake` and reports back on failure by shooting an email your way.

Since a few things bit me when setting CIA up yesterday, I’ll note them here for others to take advantage of (maybe you’re brighter than me, in this case just ignore this post).

1. Creating projects

I didn’t notice until seconds before starting this article that there’s actually a web-interface for CIA. But since CIA in itself is a Rails application, this could’ve been expected. Just fire up webrick via `script/server -e production` and set up your projects via the scaffolded views into your project model.

One thing to note is that the `path` component should not be prefixed with a slash. If you plan to let CIA work with your trunk tree, use `trunk` as opposed to `/trunk` since otherwise CIA won’t be doing anything on commit, failing to match the exact path of the changed files.

1. Permissions

Since CIA will be invoked as whatever user your subversion transport runs as (your webserver user in case of dav_svn for example) you have to make sure `/path/to/cia/data` is writable by that particular user. This is the directory that’ll hold all the checked out sources.

1. Environment

The default database.yml that CIA ships with only has the production environment configured. One could therefore assume that this is the default runtime environment. You couldn’t be more wrong. To force the hook into production mode, use the following line in your `/path/to/repos/hooks/post-commit` script:

RAILS_ENV=production /path/to/cia/script/runner \
  "Agent.build(\"$REPOS\", $REV)"

1. Database Structure

This point disturbed me the most. Since CIA invokes `rake` with the `default` target, it goes and tries to rebuild your test database from the structure found in the development database. Now, if you’re like me and develop locally and run CIA remotely it’s very likely your remote development database either doesn’t exist or simply isn’t 100% up to par with your latest developments (especially since CIA is invoked immediately after commit). As there is no `rake` task to use `db/development_structure.sql` (which is nicely updated locally when running your tests) instead of the actual development database when setting up the testing tables, I’ll probably whip up a quick script to do just that.

That’s it for now, additional information will be published here if necessary.