Hudson seemed
quite nice when I was looking at how
drizzle use it.
I proposed it to the squid project to replace a collection
of cron scripts - and we're now in the final stages of
deployment: Hudson is running, doing test
builds. We are now
polishing the deployment, tweaking where and how often
reports are
made, and adding more coverage to the build farm.
I thought I'd post a few observations about the friction
involved in getting it up and running. Understand that I
think its a lovely product - these blemishes are really
quite minor.
Installation of the master machine on Ubuntu - add an apt
repository, apt-get update, apt-get install.
Installation of the master machine on CentOS 5.2 (Now 5.3):
make a user by hand, download a .war file, create an init.d
script by copy-and-adjusting an example off the web. Plenty
of room to improve here.
Installing slave machines: make a user by hand, add an
rc.local entry to run java on slave.jar as that new user.
This could be more polished
Installing a FreeBSD 6.4 slave: manually download various
java sources to my laptop, scp them up to the FreeBSD
machine, build *java* overnight, then make a user, add an
rc.local entry etc. _Painful_.
The next thing we noticed was that the model in Hudson
doesn't really expose platforms - but we want to test on a
broad array of architectures, vendors and releases.
i386-Ubuntu-intrepid building doesn't imply that
i386-Debian-lenny will build. We started putting in tags on
the slaves that will let us say 'this build is for
amd64-CentOS-5.2', so that if we have multiple machines for
a platform, we'll have some redundancy, and so that its easy
to get a sense of whats failing.
This had some trouble - its very manual, and as its manually
entered data it can get out of date quite easily.
So in the weekend I set out make a plugin, and ran into some
yak shaving.
Hudson plugins use maven2 to build and deploy. So I added
the maven2 plugin to my eclipse (after updating eclipse to
get the shiniest bzr-eclipse), and found the first bug - issue
1580 maven2 and teamplugins in eclipse 3.5 don't play
all that nice.
Push.
Removing bzr-eclipse temporarily allowed eclipse's maven
plugin to work, but for some reason many dependencies were
not found, and various discussions found on the net suggest
manually adding them to the CLASSPATH for the project - but
not how to identify which ones they were.
Pop.
So, I switched to netbeans - a 200MB download, as Ubuntu
only has 6.5 in the archive. netbeans has the ability to
treat a maven2 project as a directly editable project. I
have to say that it works beautifully.
Push.
I made a new plugin, looked around for an appropriate
interface, (DynamicLabellers, designed for exactly our
intended use).
Sadly, in my test environment, it didn't work - the master
didn't call into the plugin at all, and no node labels were
attached.
Push.
Grab the source for hudson itself, find the
trick-for-newcomers here - do a full build outside netbeans,
in netbeans open main/war as a project, and main/core as
well, not just the top level pom.xml. To run, with main/war
selected in the project list hit the debug button. However
changes made to the main/core sources are not deployed until
you build them (F11) - the debug environment looks nearly
identical to a real environment.
Pop.
There is a buglet in DynamicLabeller support in Hudson,
where inconsistent code between general slave support and
the 'master node' - 'Hudson.java' causes different behaviour
with dynamic labels. Specifically the master node will never
get dynamic labels. So I fixed this, cleaned up the code to
remove the duplication as much as possible (there are
comments in the code base that different synchronisation
styles are needed for some reason) and submitted
upstream.
Pop.
I'll make the plugin for squid pretty some evening this
week, and we should be able to start asking for volunteers
for the squid build farm.
Yay!