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

In the first part of this mini series we took a look at the Jenkins Job Builder from openstack. This part contains a short introduction into the second tool, the Jenkins Job DSL Plugin. At the end of this part also contains a conclusion on which tool to use.

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

The DSL Plugin uses a groovy Domain Specific Language to define jobs. A very basic job looks like this:

In order to use this job description you need to install the Jenkins Job DSL Plugin in your jenkins installation.

After that you need to define a so called “seed job” which has a sole build step for the dsl plugin in which you can paste the dsl code:


Running this job will yield the job. You can check what has been generated from the seed job by looking at the job’s page:


If you’re job definitions are part of the workspace of the seed job, you may also specify a filter that is used to pick up jobs from the current workspace:



Since feature comes in handy, if you keep your job definitions in a git repository. A complete instruction on how to set up a seed job can be found here.

There’s is also the possibility to test job definitions locally, which is described here. Beware though that a running the dsl plugin in a local environment differs from running the plugin on the jenkins server. If you access jenkin’s api in your job definitions for example, the local mode will yield an error.

If you run the local mode, a file with the resulting xml is written to a file:

I have made two additional examples. This one demonstrates the syntax for accessing a git repository. The second one shows how to create muliple jobs from one groovy file.

Reuse and templating

Since job definitions are in fact groovy scripts, all the powerful possibilities of oo programming are at your hands to reuse and templating.

I found the delegation pattern most useful for externalizing common properties of jobs. The following example which is derived from the plugin’s documentation shows an example on how to set defaults by using a utility class and then passing the job to that class:

After the jobs has been created it is passed to a utility class for setting defaults. The code of the utility class looks like this:

Beware though that the dsl ist not recognized in classes or scripts outside of the initial script. You need to pass the current context to this classes in order for the dsl to work, as described here.

Very useful is also the fact, that you actually access information about the jenkins instance from within the seed job. For example pasting the following groovy snippet in  to the dsl field of a seed job will display the root url of the jenkins instance:

The jenkins model is described in detail here. You might also take a look at the Jenkins groovy plugin which has some examples on how to use groovy scripts to access jenkins properties.


So which tool should you use ? Well, it depends of cource ;-)

There are many factors which influence the decision which tool to use. If mostly programmers create and manage jenkins jobs the DSL Plugin might be the right choice. On the other hand if people responsible for jenkins job definitions have more of a scripting / administrating background the Jenkins Job Builder might be the right choice.

The following lists contain some of my key findings about both tools:

Jenkins Job Builder:

  • Easier to read (+)
  • Does not require any jenkins plugins to be installed (+)
  • More script style (o)
  • YAML format pedantic about indentation (-)
  • Definitions become less readable when applying templates and macros heavily (-)

Jenkins DSL Plugin:

  • More powerful API because of groovy (+)
  • Requires the DSL Plugin to be installed (-)
  • Common Libs may be shared for example using maven (+)
  • Integrates seamlessly with jenkins (+)
  • Job definitions harder to read (-)

When deciding on one of the tools I suggest trying out some sample scenarios and then -after all we life in a DevOps world- let the team decide.

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="">