3 ms·
Also highly recommended is Jenkins Job DSL, which, despite also using Groovy like Jenkins Pipeline, takes a far different approach. In Job DSL, you write Groov
by rhencke 8y ago
Also highly recommended is Jenkins Job DSL, which, despite also using Groovy like Jenkins Pipeline, takes a far different approach.
In Job DSL, you write Groovy scripts to declare your job. These scripts, in turn, write the config.xml that Jenkins uses to actually define and execute jobs.
One of the big benefits to us is that it is _not_ an alternate execution engine like Jenkins Pipeline is. It just takes over the job of writing the job XML for you, instead of editing it through the GUI.
We had a large, complex, manually 'versioned' job chain that did not lend itself to being re-written in Jenkins Pipeline, as it made heavy use of plugins that were not supported by Pipeline at the time.
By using Job DSL, we were able to incrementally replace the manually maintained jobs with script-generated ones. Importantly, with nothing breaking for end users! All download links, URLs, etc of the new jobs exactly matched the old ones, so it was a very painless, incremental adoption that people did not even notice!
If you've got an existing job chain you are trying to get under control, Job DSL comes highly recommended.
- humbleMouse 8y agoAgreed, I love the groovy jenkins job DSL. It's so awesome and simple. Easy to put everything on github and forget about it.
- vorg 8y agoBesides all the special cases in the normal use of Apache Groovy (e.g. definition of `==` different to Java), you also have to remember all the Jenkins-specific special cases (e.g. Groovy's collections methods don't work). I wouldn't call it simple or easy at all.
- humbleMouse 8y agoI don't do fancy things in my jenkins builds, so your mileage will vary.
- rhencke 8y agoAre you sure you're not thinking of Jenkins _Pipeline_? Jenkins _Pipeline_ definitely has these issues. Jenkins _Job DSL_ has always worked fine, including all the special collection method operations (grep, find, collect, each...)
- quacker 8y agoJust to add, Jenkins Job Builder supports configuring jobs that use the Job DSL plugin[1] in addition to a variety of other ways to configure jobs. 1. https://docs.openstack.org/infra/jenkins-job-builder/builders.html?highlight=dsl#builders.dsl https://docs.openstack.org/infra/jenkins-job-builder/builder...
- rubenbe 8y agoHaving worked with both, it is also interesting to know that Job DSL is aware of jobs that have to be removed, while Job builder is not. That was one of the reasons we chose Job DSL as our configuration method.
- epage 8y agoWe've been using jobdsl for years. We've been moving away from people authoring jobdsl. Instead we have a custom format suited to our policies. We still use jobdsl for taking care of knowing the configuration details of all of the plugins we use. We have a custom format for - Decoupling server configuration (version, plugin versions) from build configuration. This is especially important because jobdsl regularly breaks compatibility. You can't just check your build description into your repo and live on a happy life. - Reuse a lot of build steps across our different repos. We have a lot of common steps specific to use and we wanted to reduce our boiler plate. I am looking into moving off of jobdsl to jjb. In theory, jjb supports generating for multiple plugin versions. As a step towards aligning two distinct build farms, we want our custom format supported on both. Unfortunately, our build farms are on different versions of plugins. I could have our tool support generating for different jobdsl versions but am instead looking at relying on jjb's ability to do this.