We're doing some retooling of our
development environment. One of the changes we are making is swtiching from CruiseControl
. These tools provide automated builds for all of our projects and we found that Hudson was just a bit simpler to set up and manage. Our Ant and Maven based projects were a breeze to set up under Hudson but our Grails
apps gave us a bit more trouble. Most of my issues stemmed from trying to use the generated Ant build.xml in the grails application. There were a lot of tricks I had to do with environments or in editing the build.xml that I did not like. Each fix seemed to make the project less portable. So I switched from using Ant to just using Hudson's "Execute Shell" build option and everything worked great. Basically, all the environment variable setup that needed to bet set for the build under Hudson (JAVA_HOME, GRAILS_HOME) could be done in the Hudson configuration for the build and not in the project files in Subversion. My script ended up looking like:
JAVA_HOME=/usr/jdk/latest; export JAVA_HOME
GRAILS_HOME=/opt/grails; export GRAILS_HOME
$GRAILS_HOME/bin/grails upgrade <<FOO
The script executes immediately after the project is checked out in the Hudson workspace.
The odd bit of shell code that performs the Grails "upgrade" is necessary when checking out for the first time from Subversion. This is explained
on the Grails site. The "here doc" is required because the Grails upgrade command needs some interactive input from the user. Normally that's not a problem but when using an automated build you need to push the answer into the command.
This setup works perfectly, gives me the control I need to perform the build, and keeps my project artifacts free from environmental specificity. If anyone knows a better way I'd love to hear about it.
Technorati Tags: grails, hudson, continuousintegration, tools