Jenkins, Configuration as Code, and Job Definition (featuring Ansible)
I have been using Jenkins on and off since it was still called Hudson - with the “off” periods being more because it didn’t need any further maintenance or changes, it just happily keeps chugging along in the background). Over that time there have been some big leaps in the approach to configuration like declarative pipeline definitions allowing programatically defined pipelines, but I had thought that the initial configuration of Jenkins was still limited to ClickOps (or using their REST API directly).
I have been working lately on digitising a bunch of DVD box sets that I have that are either not available on streaming services, or include soundtracks that have changed in what is available. Part of my workflow for this includes includes transcoding the files to reduce their file size from the raw DVD rip. For years I have used the video_transcoding project from Lisa Melton for this purpose.
While there are more dedicated tools available for this type of batch processing, I figured it was time to reintroduce Jenkins into my homelab for a bit of future experimentation.
The Initial Setup & Configuration as Code
In the Jenkins documentation there was a docker run example that I could have converted into a docker compose file, but I was being a bit lazy and jumped over to ChatGPT to get me started. This, as well as giving me what I wanted, suggested some Jenkins plugins that I had not encountered before - including the Jenkins Configuration as Code Plugin. To quote it’s documentation:
The ‘as code’ paradigm is about being able to reproduce and/or restore a full environment within minutes based on recipes and automation, managed as code.
Manage configuration as human-readable config file(s) Setting up Jenkins is a complex process, as both Jenkins and its plugins require some tuning and configuration, with dozens of parameters to set within the web UI manage section.
Jenkins Configuration as Code provides the ability to define this whole configuration as a simple, human-friendly, plain text yaml syntax. Without any manual steps, this configuration can be validated and applied to a Jenkins controller in a fully reproducible way. With JCasC, setting up a new Jenkins controller will become a no-brainer event.
I always aim for easily reproducible setups, so this is perfect for my setup.
The initial configuration files ChatGPT gave me were not entirely correct, but it gave me enough of a pointer that I could look for the right information.
At present my Configuration-as-Code directory contains files to configure:
- Using ephemeral Docker containers for build nodes
- SSO authentication using Authentik and OpenID Connect (I have not got to role based authentication yet, so it’s pretty wide open once you are authenticated)
- The URL Jenkins is running at
- Some pipeline jobs which are static, as in their pipeline definition is set at the point I configure Jenkins and do not come from a source control repository of their own
This fourth point had some interesting challenges that I thought was worth sharing.