Automating Jenkins Job Configuration with Job DSL

Why use Jenkins Job DSL

Some might say I’m a lazy engineer, but I prefer to think of myself as efficiency-oriented. I simply don’t like to execute repetitive and tedious tasks. So, when I work with Jenkins, I leverage the heck out of Jenkins “Job Domain Specific Language (DSL)”, a plugin that lets me manage all of my Jenkins jobs’ configurations as code. I can describe my jobs in Jenkins using a Groovy Based Language, in a human-readable file, as close as possible to natural language.

The benefit of Job DSL is that not only does it allow me to skip the manual steps of tinkering with jobs in the GUI to fetch the Jenkins files stored in my project, it also takes another step further than that, as I can populate folders, jobs, and more, all through one manually created Jenkins job and a (git) repo.

Two other benefits of using Jobs DSL are:

1. Standardize your pipelines
   By leveraging Jenkins job DSL, I can build a guardrail to enforce teams to work in a controlled way, without limiting any flexibility for sandboxing. I can simplify and enhance DevOps lifecycle for applications to get the job done faster and better for customers.

2. Define jobs in a more human-readable language
   Jobs DSL takes over the job of writing the job XML so I don’t need to edit it through the GUI

How to use Jenkins Job DSL

In this tutorial, I’ll show you how to use Job DSL to configure two demo jobs.The first job, which is called a “seed job”, will print a ‘Hello World’ message in the console and the second job will run a pipeline from a Git repository. If you follow the tutorial to the end, you will have a foundational Job DSL script that you can build on for your own use cases.

Prerequisites for Job DSL

Here is what we need to get started.

1. A Jenkins server. We can  either set up a Jenkins server via the setup wizard or by using Jenkins Configuration as Code (JCasC).
2. Git to integrate Jenkins with Git repositories.

Using Jenkins Job DSL – Step by Step

Once you have your Jenkins server all set up, follow these steps.

Step 1: Install the DSL plugin

Before creating jobs, you’ll first have to install the Jenkins DSL plugin:

1. Verify your Java version on your Jenkins server

#java -version && systemctl status jenkins

by connecting via SSH to your Jenkins server and running the following command:

2.  Open your Jenkins Plug-in Manager:

Use a browser to navigate to 

http://your_server_ip:8080/pluginManager/available. 

Replace your_server_ip:8080 with your Jenkins server’s actual DNS/IP address and port number.

3. Install Jenkins DSL Plugin with the following:

1. Type in “Job DSL” in the search box on the top right.
2. Check the checkbox beside the Job DSL option.
3. Select “Install without restart” at the bottom to install the Jenkins Job DSL plugin.

Step 2: Creating a Jenkins Seed Job Using the Jenkins DSL Plugin

Now that you have the Jenkins DSL plugin installed, you can create a Jenkins seed job mentioned earlier by writing a basic Job DSL script and incorporating the script into a Jenkins seed job. Your job will print out a ‘Hello World!’ message to the Jenkins console.

To incorporate a Job DSL script into a Jenkins seed job:

1. Navigate to Jenkins Dashboard, then select “New Item” in the left sidebar. 

2. You will be  redirected  to another page where you can create a new item.

3. Create a new item with the following:

• Item name is set to “seed” in this tutorial.

      – Freestyle project (a repeatable build job, script, or pipeline) from the options.

4. Select “OK” at the bottom to create the new item. You will be redirected to the new item’s configuration page.

5. Keep the default settings for all other sections on the new item’s configuration page.

6. Scroll down to the Build section, select the “Add build step” dropdown button, and select Process Job DSLs. You will be prompted with an option where you can provide a DSL script.

7. Select the “Use the provided DSL script” option, and populate the following code block to the field. This code block is a freestyle job definition named ”jenkins-job-kubiya-1″ that uses the shell step to print a “Hello World” message. The job’s name is what will appear in the Jenkins UI.

job('jenkins-job-demo-1') { // Sets the name of the job to jenkins-job-demo-1  
  steps {  
      shell('echo Hello World! This is Kubiya!!')
    }
}

8. Select “Save” to save the configuration for the new item (seed).

9. Navigate to your Jenkins Dashboard to verify the seed job I have just created exists.

Step 3: Running a Seed Job

In this step, I’ll run the seed job against the DSL script ”jenkins-job-kubiya-1″.

1. On the Jenkins Dashboard, select on the “seed” job to open its configuration page.
2. Select “Build Now” in the left sidebar to run the job.
3. Verify the job ran successfully. I can see a new build appear under the Build History section with a success status (green check).
4. Navigate to the Jenkins Dashboard. I can see the new Jenkins job (jenkins-job-kubiya-1) created by the “seed” job.
5. Select “Build Now” to run the generated job (jenkins-job-kubiya-1).
6. Verifying output by selecting the drop down button next to the successful build under the “Build History section”. Choose Console Output from the context menu to see the job’s output.
7. Because the generated job works, I can see the message saying “Hello World! This is Kubiya!!”.

I’ve successfully created and run a Jenkins job using the Job DSL plugin.

How to monitor Jenkins Jobs

Maintaining visibility and control of your environment is crucial for a successful DevOps automation strategy. There are multiple ways to manage and monitor your Jenkins DSL jobs, from using built-in features or third-party tools like Prometheus or Datadog. Both require complex setups and learning curves to get used to the management interfaces. By using Kubiya, you can manage and monitor your Jenkins jobs with ease by communicating with Kubiya in plain English. I will cover that in a later post.

Summary

In this tutorial, I have shown you how to create Jenkins jobs with the Job DSL plugin to help you eliminate a lot of manual labor and human error working with Jenkins jobs. As a result you will spend a bit more time  but far less time managing your DevOps shop. With a security-first mindset,  you should also lock down a job to owners or administrators only, and require that only code reviewed configuration is usable. Scripts can only be executed with the right review and approval process. While this is a best practice, it can add management burden to the administrators. I will cover in a later post on how to use Kubiya to seamlessly review and approve seed jobs from non-administrator users.