JUC Session Blog Series: Daniel Spilker, JUC Europe

Daniel Spilker's talk "Configuration as Code - The Job DSL Plugin" continued a theme from Kohsuke's keynote speech: Maintaining a large number of jobs through the Jenkins UI is difficult. No single job builds everything; you may even need complex build pipelines for every branch. This means: Lots of copy & paste between jobs and manual editing of text areas in the Jenkins UI. And if you miss important options behind 'Advanced…' buttons, you'll need a few attempts to get it right!

What you want instead are ways to set up new build pipelines quickly, to be able to refactor jobs without hassle, to have traceability of job configuration changes and to even be able to use IDEs for any scripts you're writing.

Since this is a common problem, several plugins exist that address some of these problems: Job Config History plugin allows you to determine who changed a job configuration; Literate Plugin stores the configuration in an SCM and can build multiple branches; Template Project plugin allows to reuse parts of job configurations in other jobs; Workflow Plugin makes it easy to build job pipelines. And then of course there is Job DSL Plugin, which aims to accomplish all of the goals mentioned above.

The Job DSL Plugin provides a DSL (domain specific language) based on Groovy that makes UI options available as keywords and functions. For example, a simple job definition could look like the following:

job('job-dsl-plugin') {
scm {
github('jenkinsci/job-dsl-plugin')
}
steps {
gradle('clean build')
}
publishers {
archiveArtifacts('**/job-dsl.hpi')
}
}

To use this DSL in Jenkins, you need to install the Job DSL Plugin and set up a so-called 'seed' job: A freestyle project that has a 'Process Job DSL' build step. When you build this seed job the specified Job DSL (e.g. stored in SCM) will be evaluated. In the example above, a job 'job-dsl-plugin' will be created if necessary, and then configured to check out from GitHub, build using Gradle, and archive a generated artifact.

The Job DSL plugin has a large user community of 70 committers that so far have created 500 pull requests and added support for 125 other plugins in the DSL, like the Gradle and Git plugins shown in the example above. Despite its name the plugin can also be used to generate views and items that aren't jobs, such as folders from the CloudBees Folders Plugin. If a plugin is not specifically supported by Job DSL, users can still make use of it by generating appropriate XML for the job's config.xml.

Since the DSL is based on Groovy, users can use features such as variables, loops and conditions in their DSL. Users can even define functions and classes in their scripts. Any Java library can be used as well, provided it was made available in the job workspace e.g. by a simple Gradle build script before executing the Job DSL script.

Advanced features of Job DSL include the ability to use IntelliJ IDEA to write DSL scripts, as the 'core' part of the Job DSL is a Java library, and a command-line version of Job DSL to generate job configurations outside Jenkins that allows you to review changes in job configurations before applying them to make sure what you're generating is correct.

Daniel ended the talk with some best practices, like recommending that adoption of Job DSL should happen gradually, that Job DSL scripts should always be stored in SCM to get traceability, and that smart use of Groovy will avoid repetition.

We hope you enjoyed JUC Europe !

Here is the abstract for Daniel's talk, "Configuration as Code: The Job DSL Plugin".

Here are theslides for his talk, and here is the video .

If you would like to attend JUC, there is one date left! Register for JUC U.S. West, September 2-3 .