Configuring Jenkins Buildnodes the right way

A few weeks ago I gave a presentation at the Jenkins User Conference London 2015 about how we have set-up and use Jenkins to power our builds. One idea I mentioned in the talk and I`d like to share now is how we bind our jobs to specific buildnodes. Given the fact that we are doing lots of different projects for different clients we have quite a few buildnodes to cover every use case we need. When we started using Jenkins about 4 years ago we bound every job to a set of specific buildnodes (e.g. buildnode01 || buildnode02). When our setup grew, it was not easy to keep up-to-date to figure out which buildnodes offer which capabilities. In the end this lead to jobs failing every now and then because Jenkins picks a buildnode from the list which does have all the required tools installed, this behaviour I call the "Jenkins law".

The "fix" was simple and effective: Making use of the labels feature of a buildnode. I am able to assign labels to a buildnode and refer to the labels in the job configuration. Labels for us represent the "features" offered by the buildnode itself. A feature could be "php56", "php7", "hhvm", "java8" or "npm". In the job configuration I can then use boolean algebra to select the buildnodes for the job by simply defining what features are needed to run the job, e.g "php56 && npm". Jenkins will then try to figure out if there's a buildnode available where the expression matches and also report back the amount of buildnodes found for the given expression. Problem solved.

Ideally Jenkins could figure out by himself which features are offered by a buildnode and set the labels accordingly. Currently, this is manual work to keep the data in sync. Luckily we do not change the buildnodes regularly so currently this is not big deal for us. In the future I`d like to see a Jenkins plugin which would somehow read the information from the buildnodes.