Skip to Main Content
Official App
Free – Google Play
Get it
FreshBooks is Loved by American Small Business Owners
FreshBooks is Loved by Canadian Small Business Owners
FreshBooks is Loved by Small Business Owners in the UK
Dev Blog

Using Jenkin’s JSONP API for pretty profit

by Mark on April 11/2011

In a previous post Corey talked about how we’re using Hudson (now known as Jenkins) to manage our automated builds and display build status on a monitor looming above all the developers. As our internal portfolio of projects has grown our existing statusboard has gotten long in the tooth. I recently took the time to re-design and re-implement our statusboard’s front end so it can display more information in a more consistent manner.

In the previous iteration we were using the Jenkins Radiator view plugin to provide project build statuses. For this iteration, I decided we could have a more seamless display by using Jenkins’ JSONP API. Jenkins not only provides great features, it also exposes most of them through XML, JSON, and JSONP APIs. I used the JSONP API, as our statusboard isn’t hosted on the same domain/virtual machine as our Jenkins server.

Jenkins’ JSON APIs support two ways of digging information out of it. The first is the depth parameter, this allows you to give an integer of how ‘deep’ of information you want from Jenkins. Unfortunately for me the information I wanted was at a depth of 2, which also resulted in 1.3MB of JSON data, making it a bit unwieldy to consume. Thankfully Jenkins also supports a tree parameter that allows you to selectively pull data out regardless of its depth.

There are some tricks to using the tree mode of Jenkins’ JSON API. The first is that you have to know exactly what you want. If you don’t know the exact keys that contain the data you want, you can’t get it. Also you can’t do anything like a * selector for a subtree. Each and every key you want needs to be part of your query. I ended up using the following query, which gave me all the information I needed to build our statusboard:[name,color,buildable,healthReport[description,score,iconUrl],builds[changeSet[items[msg,user]]]]

This query gives the following things:

  • The job name and colour, which are self explanatory.
  • The healthReport, which contains useful information like how many tests are passing/exist for projects that create xunit reports. It also includes coverage statistics for python projects. Generating coverage reports with PHPUnit is unreasonably slow for the whole application, so we’ve turned it off.
  • The builds key contains a list of the changeSets with the messages and user who did the change set. This is used to blame people when they inevitably break the build.

This is all the information I needed to update our statusboard. This information is munged and passed through some Mustache templates to generate our build status. The display updates periodically by polling the JSONP endpoint. The previous version of our statusboard used the Radiator plugin to generate the build statuses and display them. For this iteration we only use radiator to control what displays on the build status.

The display is built entirely in Javascript, leveraging CSS3 and HTML5 to make it a bit slicker than before. Flot was used to generate the pie graphs, and everything else is basic HTML and CSS3 tricks. At the end of the day our statusboard ended up looking like:

status board

So far feedback from the team has been largely positive, as information is easier to read and there is more information to look at. As we all know developers like simple shapes and bright colours, and the new statusboard has both.