Jenkins Job Builder and Jenkins DSL Plugin compared. Part I: Jenkins Job Builder

Probably two of the best tools for creating jenkins jobs programmatically are the Jenkins Job DSL Plugin and the Jenkins Job Builder. In this two part post contains a short introduction and comparison of these two tools. This post includes an introduction to the Jenkins Job Builder.

All the examples used in this introduction are available here along with a short description on how to run the examples.

The Jenkins Job Builder comes from Open Stacks Infrastructure components. It uses job definitions in YAML format to generate jenkins job xml structure and upload them to a jenkins server. A simple job looks like this:

As you can see it is very easy to read and can be edited with a simple text editor (although yaml highlighting would be a plus).

Before you can convert this yaml to a jenkins job you have to install the job builder as described next. There is also an excellent and exhausting documentation available here.

The first step is to clone the git repository:

ant then install it:

This instructions assumes that you have the python package manager “pip” installed. If not you can install it using yum:

When I first ran the job builder on my machine, I got an the error message:

No module named pbr.version

And I had to install the python package “Python Build Reasonableness” from openstack:

No you can run the jenkins job builder like this to see the xml actually generated:

The xml output looks something like this:

To actually upload the job to a jenkins server you first have to create a configuration file “jenkins_jobs.ini”. You can either place the file in “/etc/jenkins_jobs” or specify the exact location to the jenkins job builder using the “–conf” parameter.

The following command lets you upload the job:

You can then take a look at the resulting console through the jenkins UI:


This wasn’t to hard. We will no delve into more details of the job builder especially how to generate jobs from templates.

Reuse and templating

When having a large number of jobs to create the obvious need for templating and reusing common parts in job definitions arises. The Job Builder offers three ways for that:

Not that if you scatter the definitions that make up your jobs over multiple files you have to tell the jenkins-jobs program to include all the directories and files that contain parts of the job definition.

For example if you define your defaults in a file defaults.xml and the jobs that uses them in a file job.xml, jenkins-jobs need to be passed both files as a parameter. Or the parent directory. How to do that is described here in detail.

Now back to reusing parts of your jobs: Default values for jobs may be put in separate files and reused in job definition files. The following file contains a definition for default values:

And these default values may be reused as follows in job definitions:

As the name implies, default are fixed values. In order to parametrized job definitions, templates may be used. Templates follow the same structure as job definitions with the exception that you may use parameters:

The above yaml file defines a template which expects a parameter name. Note that a template must contain a parameter in the name attribute. Otherwise all the job derived from the template would have the same name.

To use templates a project needs to be defined, in which the template is used:

The example from this file contains the project definitions which use the template “{name}-build” and use two different names. As a result two jobs are generated.

If you do not intent to reuse whole job definitions but only certain parts, macros might be the right choice. Macros let you externalize and parametrize certain sections of a job:

The above example defines a macro named “add” that adds a shell build step with a parameter. To use this template, it has to be inserted in the job definition:

In the example above three build steps are inserted with different values for the number.

Apart from these three mechanism, there is the possibility to use yuml anchors and aliases to include arbitrary pieces of a yuml file at another position. See here and here for more information. If those two approaches actually increase the readability of the job definitions remains questioned.

Finally the Jenkins Job Builder supports almost all popular jenkins plugins. But in rare case where a plugin is not supported you may actually extend the job builder, as explained here.


The jenkins job builder is easy to setup and uses plain text files for job definitions, which lets you get up and running quiet easily. At the same time it offers powerful mechanisms for templating, reuse and programtically generated jobs. Which is important in bigger projects and companies.

And last but not lease it does not require any plugin to be installed in jenkins.

In the next post of this series we will be looking into the Jenkins Job DSL Plugin which overs DSL and groovy based job definitions. That part also contains a comparison between the two tools.

One thought on “Jenkins Job Builder and Jenkins DSL Plugin compared. Part I: Jenkins Job Builder”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">