This post originated from an RSS feed registered with Ruby Buzz by Patrick Lenz. Original Post: Setting up CIA: Continuous Integration Automater Feed Title: poocs.net Feed URL: http://feeds.feedburner.com/poocsnet Feed Description: Personal weblog about free and open source software, personal development projects and random geek buzz. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Patrick Lenz Latest Posts From poocs.net

CIA 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).

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.

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.

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)"

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.