Hudson is an excellent continuous integration tool and has become an indispensable assistant in software quality control for many organizations. As for this post, I will describe how to couple Hudson and Grails to work in effective synergy.
In 2011, Hudson was split into two branches: Hudson and Jenkins, and for now, they are twin brothers. I will refer to Hudson throughout this post, but for those who like Jenkins more, just replace all ‘hudson’ words with ‘jenkins,’ and you’ll get pretty much the same result.
On Debian-based distributions, such as Ubuntu, you can install Hudson through apt-get.
sudo sh -c "echo 'deb https://hudson-ci.org/debian binary/' > /etc/apt/sources.list.d/hudson.list"
sudo apt-get update
sudo apt-get install hudsonAlongside the common installation, this package will create a ‘hudson’ user and will launch Hudson under it as a daemon on system startups.
Alternatively, you can download the Hudson artifact manually from https://hudson-ci.org and run it with
java -jar hudson.warThis will start Hudson running on the default port 8080, if you want you can change it by providing http port parameter in command line in the form of –httpPort=8070. Or change the value of HTTP_PORT in /etc/default/hudon (on Ubuntu).
Hudson already can run arbitrary scripts and commands out of the box, but the most convenient way to work with Grails projects is by using a Grails plugin. To install it, take a view of the panel on the left side and navigate to ‘Hudson -> Manage Hudson -> Manage Plugins’, then select the Grails plugin in the ‘Available’ tab. After completing the download, don’t forget to restart Hudson for the plugin to take effect.
Finally, Hudson might manage to find Grails on the system path, but it’s better to specify it explicitly by going to ‘Manage Hudson -> Configure System’ and providing the path to your Grails installation in Grails Builder.
Now, when all the setup is done, it’s time to issue a job for our servant. As an example, I’ll show how to make Hudson poll the Subversion repository every 10 minutes and fire Grails integration tests in case of any new commits detected.
Click ‘New Job’ on the left menu, then give the job a name and select the ‘Build a free-style software project’ option. In the job configuration menu, scroll down to the Source Code Management section, choose Subversion (or any other VCS of your choice), and fill in the Repository URL. It will ask you to provide valid credentials; I hope you already have an answer to this question. In the Build Triggers, you can specify a schedule in cron syntax to poll the source code management system.
That’s what it’s for: source code acquisition. Now let’s proceed to the actual build configurations. In the build section, add ‘Build With Grails’ and choose the Grails installation you want to use. The targets field contains Grails commands that Hudson will execute. You can invoke several targets in the same line; however, you need to enclose each command, including its arguments and options, in double quotes.
Note the –non-interactive option. As you are running the script not manually, but as an automated process, there’s no one to answer the questions, like whether to install a missing plugin. The non-interactive option is the workaround for this issue. With this option, any queries will be automatically answered with the default option (which is usually a sensible choice), and the build will continue.
The other fields may be left blank if this is the only job you are running. But in case you have many simultaneous job executions, it’s wise to set a different port and working directory, which Grails will be operating on, for every separate build.
That’s all, a job for continuously testing your code is ready. But, of course, this is not the limit, as you can extend Hudson’s duties with whatever you want, like deploying, code coverage reports, alerting on fails, and much more.
