Creating a Job DSL seed job with JCasC
Tags: devops, jenkins, jobdsl, jcasc
Published: 2020-07-10 21:00:37

---
title: Creating a Job DSL seed job with JCasC
published: true
date: 2020-06-23 14:00:00 UTC
tags: DevOps,Jenkins,JobDSL,JCasC
canonical_url: https://gerg.dev/2020/06/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)](https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/README.md) and [the Job DSL](https://github.com/jenkinsci/job-dsl-plugin) 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.