Grails & Hudson Part 2: Back to basics

Ok, so you’ve decided that you want to use Hudson to build your Grails projects (or have read part 1 and want to use CodeNarc too).
If you don’t know where to start, you’ve come to the right place.

The basic steps (and we’ll go into more detail on each one) are:
1. Download Hudson
2. Run Hudson
3. Download Hudson plugins
4. Configure Hudson
5. Create a Hudson job
6. Watch the trends

This post will get you started and subsequent posts in the series will add even more power to your CI process.

Step 1 – Download Hudson

Hudson is packaged as a Java web application archive (war file) and can be downloaded from
The 1.373 war is available from here.

Debian/Ubuntu users can install Hudson using ‘apt-get install hudson‘ (but if you’re on stable, it isn’t the latest version).

Step 2 – Install/run Hudson

Before we dive into the installation, you’ll need some pre-requisites installed:
– Java JDK (6 is best)
– Grails (whichever version you’re using)

As previously mentioned, Hudson comes as a war file and so it can be deployed to a servlet container such as Tomcat. The Hudson war file also includes the lightweight Winstone servlet container so can be run using:
java -jar hudson.war

Note that Hudson uses ~/.hudson as a working directory by default.

Key folders are:
jobs – job configuration, the workspace and builds are stored here
plugins – plugin .hpi files are unpacked to directories beneath this
war – the Hudson war file is unpacked here

Step 3 – Download Hudson plugins

Once you’ve got Hudson running – we’ll start by getting the Grails plugin.
Click on the “Manage Hudson” menu item

Click on “Manage plugins”

Go to the available tab, find & select Grails, click on the install button.

When the plugin has downloaded and installed, you will need to restart Hudson (you can use the button provided).

Note: you can also manually install downloaded/compiled Hudson plugin .hpi files into ~/.hudson/plugins

Step 4 – Configure Hudson

Now we need to set-up the JDK and Grails – so have their paths handy.

Click on the “Manage Hudson” menu item

Click on “Configure System”

Step 4.1 Set-up the JDK

  1. Give it a name
  2. Set the JAVA_HOME

Step 4.2 Set-up Grails

  1. Give it a name
  2. Set the GRAILS_HOME

Congratulations, you’re now ready to set-up your first Hudson job.

Step 5 – Create a Hudson job

If you have lots of Grails projects, you’ll only need to do this from scratch the first time as Hudson allows you to copy existing jobs.

Click on the “New Job” link

  1. Enter a job name (Tip: Hudson will use this for a directory name – so be careful what characters you use)
  2. Select “Build a free-style software project”
  3. Click “Ok”

For the first pass at the configuration, let’s assume that you have a working copy of the code locally (you can always come back to set-up the Source Code Management settings).

We need to add the Grails build step, so click on “Add Build Step”

This will give you an option list – select “Build With Grails”

You can now perform the basic configuration of the Grails step. Let’s set it to do a clean, followed by execution of the unit tests:
clean "test-app -unit"
Unless you’ve set up the SCM configuration, you’ll want to specify the root of the Grails application in the “Project Base Directory” too.
Finally, we want Hudson to publish the unit test results (this is relative to the workspace under ~/.hudson/job/Example/workspace).

If the working copy is clean, Hudson may complain that the XML results or the target directory do not exist – this can be safely ignored for now.

Now ‘Save’ the job using the Save button at the bottom of the form and test it using the “Build Now” link.

If the build passes, it will be marked as blue (this can be changed to green balls with a plugin).
If the build fails, then click on the failed job

and look at the error message under “Console Output”.
E.g. If you select Subversion as an SCM option, but leave the form blank:

Step 6 – Watch the trends
Assuming you’ve got it all working – after you’ve performed a few builds, Hudson will start to show build trends on the job page…

We’ll add more statistics to this view in later posts in the series.

It is advisable to pick a specific Grails installation rather than leaving ‘(Default)’.
Check your job configuration if you see errors such as:
FATAL: command execution failed Cannot run program "grails" (in directory "/var/lib/jenkins/jobs/GGUG/workspace"): error=2, No such file or directory


9 responses to “Grails & Hudson Part 2: Back to basics

  1. Pingback: Tweets that mention Grails & Hudson Part 2: Back to basics | Lean Java Engineering --

  2. Pingback: Grails & Hudson Part 3: Testing | Lean Java Engineering

  3. Pingback: Grails & Hudson Part 3: Testing

  4. very gr8 Tutorial.

  5. Pingback: Grails & Hudson Part 4: Automated Deployment | Lean Java Engineering

  6. Pingback: Grails & Hudson / Jenkins Part 5: Monitoring build status | Lean Java Engineering

  7. Hans Westerbeek

    It’s a pitty that the grails builder let’s Hudson think the build completely failed when it should be regarding it as ‘unstable’. E.g. when one or more tests fail.

    Do you know of any solution?

  8. Pingback: Grails & Hudson / Jenkins Part 5: Monitoring build status

  9. Pingback: Grails & Hudson / Jenkins Part 6: Sonar | Lean Java Engineering

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s