Generating Jenkins jobs automatically helps teams avoid repetitive UI work, reduce configuration drift, and review CI changes in version control. This guide is for DevOps engineers who manage many similar jobs and need a practical map of the available approaches.
Originally published on 2016-08-17; fully revised and updated.

Main options for automatic Jenkins job generation
The original post listed several ways to automate Jenkins configuration. The table below summarizes what each option is meant to do and where to read more.
| Option | What it automates | Best fit | References |
|---|---|---|---|
| Job DSL Plugin | Programmatic creation of Jenkins projects using a DSL script. | Teams that want Jenkins job definitions in code, generated by a seed job. | Plugin page Tutorial |
| Multi-Branch Project Plugin | Creates sub-projects for each branch from shared configuration. | Repositories where branch-based job creation is required. | Plugin page |
| Job Generator Plugin | Adds a “Job Generator” job type that creates projects when executed. | Use cases that need runtime generation of jobs from a generator job. | Plugin page |
| Jenkins Job Builder (JJB) | Defines Jenkins jobs in YAML or JSON and applies them via CLI. | Teams preferring YAML-based job definitions outside Jenkins. | JJB docs Example write-up |
| Templates + parameterized builds | Uses reusable templates and parameters to reduce manual duplication. | Organizations creating many similar jobs frequently. | Case study |
Typical workflow for jobs-as-code in Jenkins
flowchart TD
A[Store job definitions in Git] --> B[Seed job or jenkins-jobs CLI runs]
B --> C[Generate or update Jenkins jobs]
C --> D[Optional branch-based job creation]
D --> E[Builds run with shared standards]
E --> F[Changes reviewed and audited in Git]
Example: generate jobs with Job DSL
A common pattern is to keep DSL scripts in Git and execute them from a seed job. The snippet below shows a simple generated freestyle job.
folder('services')
job('services/sample-java-build') {
description('Generated by Job DSL')
scm {
git('https://git.example.com/team/sample-java.git', 'main')
}
triggers {
scm('H/5 * * * *')
}
steps {
shell('./gradlew test')
}
}Code language: JavaScript (javascript)
A seed pipeline can then apply all DSL files in a repository path.
pipeline {
agent any
stages {
stage('Generate jobs') {
steps {
jobDsl targets: 'jobs/**/*.groovy', removedJobAction: 'DISABLE'
}
}
}
}Code language: JavaScript (javascript)
Example: manage jobs with Jenkins Job Builder (YAML)
Jenkins Job Builder lets you store human-readable YAML and push it to Jenkins from the command line.
- job:
name: sample-java-build
project-type: freestyle
scm:
- git:
url: https://git.example.com/team/sample-java.git
branches:
- main
builders:
- shell: |
./gradlew testCode language: JavaScript (javascript)
jenkins-jobs --conf jenkins_jobs.ini test jobs/
jenkins-jobs --conf jenkins_jobs.ini update jobs/
Quick decision guide
- Use Job DSL when Jenkins-native job generation from Groovy scripts is your preferred model.
- Use Jenkins Job Builder when you want YAML/JSON definitions and CLI-driven updates.
- Use Multibranch when branch discovery and shared per-branch configuration are central requirements.
- Use template + parameterized patterns when reducing repetitive job cloning is the primary goal.
- Consider Job Generator Plugin only after confirming it matches your current Jenkins/plugin ecosystem.
Further reading from the original post
The original article was a curated link list. Those references are preserved below.
- https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
- https://github.com/jenkinsci/job-dsl-plugin/wiki/Tutorial—Using-the-Jenkins-Job-DSL
- https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin
- https://wiki.jenkins-ci.org/display/JENKINS/Job+Generator+Plugin
- http://docs.openstack.org/infra/jenkins-job-builder/
- https://www.slalom.com/thinking/automatically-generating-jenkins-jobs
- http://www.blackpepper.co.uk/generating-new-jenkins-jobs-from-templates-and-parameterised-builds/
- https://www.youtube.com/watch?v=ZCfrNvu6nMc (linked in the original page’s broken YouTube gallery error message)
Best practices
- Keep all job definitions in version control and require pull-request review for changes.
- Use one seed/generator path per team or domain to keep ownership clear.
- Start with naming conventions and folder standards before scaling job generation.
- Test generated configs in a non-production Jenkins first, then promote.
- Document rollback steps when generated jobs are changed or removed.
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals