We had downloaded and installed the debian package grails_1.0.4-1_all.deb from the GRAILS site, configured the GRAILS_HOME environment variable for our build target, and attempted to build it. We got this error:
Grails ended with a non null return code: 127
After some digging, it turns out that the debian package installs GRAILS but puts the actual executable in /usr/bin instead of just a symlink from the GRAILS_HOME. The Maven GRAILS plugin appears to be calling grails using the GRAILS_HOME path. Making a symlink to the grails executable in the bin dir of the GRAILS_HOME fixed this problem (although the symlink really more correctly belongs in the /usr/bin dir).

Trying to build again we came across a different problem, where the GRAILS version was showing up as null, causing build errors. After some googling I found this useful post, and re-installed GRAILS with the updated grails_1.0.4-2_all.deb package, repeating the steps for the GRAILS executable. Now we’re all up and running in Hudson! I hope this might alleviate some pain for anyone trying to troubleshoot this problem.

Over the years I have used a few CI servers and tools – most notably, CruiseControl (Java and .NET) and Continuum (from the Maven crew). These systems, whilst useful, cam e with a few annoyances, most notably their slight fiddliness in getting up and running. Whislt they worked, it seemed that there were always tweaks required here and there to get things running smoothly and when things went wrong they we not that easy to correct.

After chatting with a few friends, I thought I would give Hudson a try as it seems like a new contender for CI server of the month. Spurned on by glowing feedback from said friends I though I would see how easy it would be to try and aggregate our disparate CI servers (For Java and .NET) into a single hudson installation – something advertised to be easy on the tin.

Here are the steps I followed:
- download WAR, runit
- config master/slave
- config maven app
- config .NET app
- force some builds
- too easy

A simple distributed build system that works cross platform sounded too good to be true, however it seems that hudson is well on the way to being just that. I couldn’t believe how easy it was to get a distributed build/CI system up and running and building/testing our Java and .NET apps with all reports and config managed centrally. I especially like the simple reports on build trends and the weather paradigm used for displaying build stability.

After this simple proof of concept, we moved the setup to a cluster of VMWare instances (Linux and windows) so we can now build multi-platform apps and manage things centrally for all projects. This is now our main CI platform and seems to be working well.

Hurray for progress!