Grails & Hudson / Jenkins: Monitoring Build Status

There are a number of ways you can monitor the progress of your Grails build: using the Hudson / Jenkins web app; or leveraging the API: from your IDE, bespoke API clients or even your enterprise monitoring client. We’ll look at all of them here and build a simple Grails taglib to display build status in the ‘Application Status’ panel.

This is the 5th installment in the series, but the first since the announcement of the new project name of Jenkins (see Kohsuke’s post here).

Note: The particular Hudson instance I’ll be using for this post was set up with a single job for my presentation at the London GGUG and has the Green Balls plugin.

Hudson / Jenkins View Plugins
There are several plugins that provide ‘information radiators’ which make very useful wall displays for agile teams.
e.g.
radiator view

extreme feedback

IDE plugins
For developers, being able to see the build status within the IDE can be very useful (e.g. if deciding whether to check out the HEAD revision on a large project). For Eclipse/STS users they can install the hudson-eclipse plugin from the update site.

The configuration (Window > Preferences > Hudson) is quite straight forward, in this case just the URL, but there is the option to set credentials, polling interval etc.

The plugin adds a build health icon to the status bar and there is also the following view (you can trigger builds too if you have the correct permissions):

The Hudson / Jenkins Jobs API
This is the basis for the examples that follow – we’ll primarily be looking at the restful GET methods that return JSON data.

If you get “http://localhost:8081/api/json” (replacing the hostname & port as appropriate), the JSON response includes a list of jobs e.g.

"jobs":[{"name":"GGUG_trunk","url":"http://localhost:8081/job/GGUG_trunk/","color":"blue"}],

Note that the ‘blue’ color denotes a successful build – even if you’ve got the ‘Green balls’ plugin installed.

If you get “http://localhost:8081/job/GGUG_trunk/api/json” (replacing hostname, port & job name as appropriate), the JSON response includes:

"displayName":"GGUG_trunk",
"name":"GGUG_trunk",
"color":"blue",
"lastBuild":{"number":33,"url":"http://localhost:8081/job/GGUG_trunk/33/"},

The API has built in documentation see e.g. http://localhost:8081/api/? and http://localhost:8081/job/GGUG_trunk/api/?

Groovy scripts
Now we’ve had a quick introduction to the API, let’s look at two simple cases for a Groovy script: status of all jobs and more information on a specific job.
For simplicity we’ll use the Groovy helper getText() method on java.net.URL – if you’ll need authentication I’d recommend using Apache Commons HTTP Client instead.

Using the top-level API:

Gives the output: GGUG_trunk – blue

Or a for a specific job:

We get the output: GGUG_trunk #33 – blue

Grails taglib
Building on what we’ve just achieved (but replacing json.simple with the Grails helper classes), we can display this information in our Grails application (again see caveat about authentication).

This can now be included in the grails-app/views/index.gsp
e.g.

<h1>Application Status</h1>
<ul>
<li>App version: <g:meta name="app.version"></g:meta></li>
<li>Latest CI build: <g:buildInfo server="http://localhost:8081" job="GGUG_trunk"/></li>
<li>Grails version: <g:meta name="app.grails.version"></g:meta></li>

And in action:

Monitoring tools
You may also want to incorporate your application build status into your enterprise monitoring so you can have a view across the whole piece, i.e. live, staging, test & development.

Opsview has a service check that I contributed to allow monitoring of Hudson / Jenkins jobs as part of the centralised enterprise monitoring. The Opsview team use this to monitor their own jobs that test the Opsview check ins.

check_hudson_job is a Perl script that uses the JSON job API, the necessary service check arguments are URL, job name, username, password.

Output is provided in standard Nagios plugin format, but the unknown status code is returned if a build is in progress (e.g. the color contains ‘blinking’).

That concludes this series of Grails & Hudson (Jenkins) posts for the time being – hopefully you’ve found it useful as we’ve covered enough to get your Grails projects nicely automated:

Part 1 – CodeNarc integration
Part 2 – back to basics with setting up Hudson / Jenkins for Grails
Part 3 – automated testing of your Grails build
Part 4 – automated deployment of war files