Jenkins is a powerful tool for continuous integration. On my current team, we use it to build our Docker images, run unit and integration tests, and create our releases. The Jenkins UI exposes a number of details about your project: the status of builds, test results and coverage, and how long the builds take. But did you know that Jenkins also exposes a JSON API with all of this information and more?

The Jenkins JSON API is accessible in two main ways. The first way, if you only want to get a few fields about the builds, is to specify them in the URL: {host}/job/{project}/api/json?tree=allBuilds[timestamp,duration]. This will give you a JSON object with an allBuilds key, and a list of items with the requested fields.

With output in this format, you can use the gist here to generate a moving-average of your build durations for the past 30 days. Here is a plot from my team showing an improvement that we were able to make about a week ago:

before

Moving Average of Jenkins Build Times


If this visualization is useful for you, you could add additional fields to the request such as result, and filter to only successful (or only failed) builds.

The second way to access the API is to control the depth of the tree that you wish to fetch, e.g. {host}/job/{project}/api/json?depth=2. This gives more info than the request above, including the Jenkins instance where the job was built (the builtOn key). This output format would be useful for investigating certain scenarios, such as if you suspect that some of your Jenkins instances are much slower than others. My team was able to use this recently when we suspected one of the instances in our Jenkins pool was problematic. After looking at the data, we were able to determine that this was not the root cause of our issue.

Data visualization is great for being able to monitor and evaluate your build process. Knowing how to access the Jenkins API and write scripts to visualize this data can be very useful. If you find yourself running one of these scripts repeatedly, you could consider putting it behind a web endpoint to make it easier for you and your team members to access on demand.