In the script, readability and simplicity are favored over clever abstractions and DRYness. Hopefully, even people who don’t know shell scripting or Ruby can read the scripts and easily understand the commands it is executing.

A standardized environment is assumed: A dedicated Ubuntu 8.04 system, Ruby 1.8.6, and latest dependencies via aptitude. PCs and Virtual Machines are cheap, and Linux and CCRB are free. There’s really no reason you shouldn’t be able to run a dedicated CI box. If this environment doesn’t work for you for some reason, the scripts should be self-explanatory enough that you can easily hack it up to work for your environment (and contribute your version back to to the project!).

I use the magic fairy dust of GitHub to eliminate build scripts, release scripts, packaging, versions, and pretty much all the regular boring overhead of a project. The README.txt is my only documentation. The GitHub “Download Tarball” link automatically provides packaging and uniquely-named packages (by the git hex commit id) for each “release”.

I’m pretty pleased with how this turned out. I hope it will lower the barrier for people to start trying out Continuous Integration, as well as provoke some thought about simplicity and minimalism. I’ve tried it out on a few flavors of Ubuntu VMs and my personal box, and it works for me. Please let me know what you think, and feel free to offer any suggestions for improvement.

Since your README.txt suggests the use of `wget`, I suggest you install this in your setup scripts. As for OpenSSH, I suppose you could argue that this is extra since you already have a terminal if you are installing Cinabox.

August 25, 2008 at 5:17 am

Aaron says:

This looks awes! I’d love to run CI (with selenium & jsunit) on EC2 — are others doing that, or is VMware more appropriate?

August 28, 2008 at 6:34 am

Chad Woolley says:

Hi Aaron,

Thanks for the commend.

I’ve never tried cinabox (or any CI) on EC2, but I was discussing it some with my fellow Pivot Davis.

I think the tricky part would be to wake up the instance when a checkin happens, and a build is required. If you kept the instance running all the time and polling for commits, it would probably be expensive :) I bet you’d be better off using a VPS with a lot of memory to support a GUI.

So, the idea would be to could run some sort of notification hook on your source control server (svn or git) to send a request to fire up the EC2 CI instance, which should then detect the new commit, and do a build.

Of course, there would be edge cases here, such as svn:externals or git submodules (which would not be a commit to your repository, and thus wouldn’t trigger any hook).