The problem with using a user interface for configuring a continuous build system like Jenkins is that it doesn't scale - teams should own their Jenkins configuration, but the normal approach in the user interface is to copy and paste jobs which quickly becomes unmaintainable when applying global fixes e.g. temporary diskspace management.
This can be solved in Jenkins by using the Jenkins Job DSL plugin, which allows job configuration to be automated and scales up to 10s/100s of jobs. Teams can configure their own microservice, frontend, stubs, and test jobs in their own product-specific configuration file, using a convenience Builder pattern that encapsulates the Jobs DSL (in Groovy). If and when the existing Builders are insufficient, the raw Jobs DSL can still be used.
JobBuilder allows a job to be constructed from a series of SCM settings, publishers, and plugins. The raw Jobs DSL can be used if necessary.
ListViewBuilder allows a job list to be constructed from a series of jobs. The raw Jobs DSL can be used if necessary.
BuildMonitorViewBuilder allows a job monitor to be constructed from a series of jobs. The raw Jobs DSL can be used if necessary.
./gradlew clean testlocally to test your changes. The test suite will ensure the Builders are capable of producing the expected config XML for Jenkins.
Create a Jenkins jobs repository akin to www.github.com/hmrc/jenkins-jobs, and then create a Jenkins job that weaves together this library with the jobs repository as follows:
- Gradle Step
- Use Gradle Wrapper = true
- From Root Build Script Dir = true
- Tasks = clean build
- Process Jobs DSL Step
- Look On Filesystem = true
- DSL Scripts = DIR/*.groovy
- Removed Jobs = Delete
- Removed Views = Delete
- Context To Use For Relative Job Names = Jenkins Root
- Additional Classpath = DIR/*.jar (where jenkins-job-builders is in DIR)
The open HMRC Jenkins jobs are one example of how to use this library.
This code is open source software licensed under the Apache 2.0 License.