Creating a Job DSL seed job with JCasC

I spent a good amount of time trying to figure this out today and thought it would be worth putting out in case it helps others. I’ve been exploring different ways of automating Jenkins administration lately, which has led me to trying both Jenkins Configuration as Code (JCasC) and the Job DSL plugins. I’ll write a more complete post on that journey later, but in the meantime, I want to address a gap in the JobDSL documentation.

The introduction to Job DSL describes how to create a “seed” job in Jenkins that’ll read your Job DSL definitions and create Jenkins jobs from them. But, it only describes how to set up this seed job through the Jenkins UI. This allows us to reduce configuring all our Jenkins jobs through the UI to just one through the UI and the rest through code. But it’s still one more than I want to do.

Meanwhile, they also describe using JCasC to define jobs directly within JCasC’s configuration model, to bypass the need for a seed job at all. But, their examples imply you need to put all your Job DSL code into the YAML file read by JCasC, or an enumeration of all the Job DSL files stored somewhere on the filesystem. Any change to your jobs then also means changing your JCasC configuration.

What they don’t tell you is how to do both of those things at once: defining a Job DSL seed job directly in JCasC. This seemed like an obvious use case to me. You still get the benefit of having a repository for all your jobs as Job DSL files written in Groovy files, and instead of configuring one job manually in the UI you’d have to configure only one job in a JCasC file.

To set this up, we’re going to define a Job DSL job using Job DSL, which simply does the following:

1. Check out a repo containing all our Job DSL definitions
2. Process those files using Job DSL

and put that in a configuration that JCasC can execute when it loads.

In code, this is what it ends up looking like:

jobs:
  - script: >
      job('Job_DSL_Seed') {
        scm {
          git {
            remote {
              url 'ssh://git.example.com/project/jenkins-jobs.git'
            }
          }
        }
        steps {
          jobDsl {
            targets 'jobs/**/*.groovy'
          }
        }
      }

The first two lines are the JCasC YAML to say we’re adding a job via an inline script, while the rest is the Job DSL definition. That’s all there is to it. The scm block would be configured to point to your repository of Job DSL files, and anything that matches the jobs/**/*.groovy glob pattern will be processed by Job DSL. When the JCasC configuration is next reloaded, the seed job will be created automatically.

Of course, you can add anything else to this job you need using the Job DSL. You may need to tweak the git block if, for example, you want to use a branch other than the default one or need to specify credentials. In my local implementation, I’ve also set up a slack notification if the job fails or if anybody tries to use deprecated commands in their job definitions. To see the other options that are specific to the jobDSL { ... } step, you can navigate to /plugin/job-dsl/api-viewer/index.html#path/job-steps-jobDsl on your Jenkins instance.

The only catch with this is that you still have to run the newly created Job_DSL_Seed job manually to create all your jobs. While you could add some cron triggers to run it automatically, any new or changed job definitions need to be approved by an administrator before they take effect anyway, so there’s always going to be a manual component.