So my biggest gripe with Hudson is slave nodes. In Puppet land we need to run our tests on a wide variety of platforms – it’s a system/configuration management tool that runs on just about every flavour of *nix (and soon to be Windows) around: Linux (a bucket load of distros), *BSD, OSX, AIX, Solaris, HP-UX, amongst others. We need to ensure it builds, runs and configures things on these platforms and that new features and functions don’t break things. To do this there is a huge management overhead – especially as build/test is generally two or three people – mostly Luke and I.

In this process I’ve had many struggles with getting people to submit slaves and with managing my own slave node network for Hudson. It’s bloody annoying to have to fight RUBYLIB issues, Gem versions, installed versions of Puppet and Facter and a dozen other issues with running tests on slaves before you can even identify and fix a failed test.

I finally threw in the towel and decided to look at some other CI engines – perhaps my initial look and selection of Hudson had been premature.  But another review and installation of a wide variety of tools suggested to me that Hudson was the right choice. So an impasse.

Then along came the Hudson Amazon EC2 plug-in.  It allows Hudson to run up Amazon EC2 instances when required as slaves.  This means with a few judicious choices of AMIs I can quickly run up a test farm that covers all my requirements – Linux, Solaris, even Windows when we merge in the new Windows code (0.25.0beta2 I hope).  It’s not quite working yet – for reasons that aren’t 100% clear to me yet.   But it’s on the right path and I hope it’s going to make life much easier.  More on how it all works … when it all works..

UPDATE:  It now works – mostly a PEBCAK issue – the plug-in requires that the EC2 Security Group is configured to allow a connection on port 22 from the Hudson master.  Next steps some proper implementation…