Jenkins has survived Hudson and is a go-to UI for what used to be called Release Engineering. It can become a key element in Continuous Integration Continuous Delivery. I’ve been setting it up as a packer-ansible integration tool to build code then package it as AMI’s (Amazon Machine Images) to drop into AWS (Amazon Web Services). As it comes out of the box, Jenkins jobs are created through the UI and saved by Jenkins in the config.xml file. One of the things we want (AOL PLatform Devops) is (1) not to have to create jobs in Jenkins through the UI, and (2) to have the code for the CICD packer and ansible builds and the Jenkins job itself (config.xml) checked out as part of the repo for the application. This would include the packer.json, the ansible playbook and roles, and the Jenkins config.xml.
The git-plugin for Jenkins almost does what we want. As it comes out of the box it drops unknown repos sent to the git plugin onto the floor, that won’t do, we want it to catch and handle those cases by creating a job named for the repo and to configure that job in Jenkins either from the config.xml carried to us in the repo or from a template config.xml. The burden drops to the developers to configure their repos with the correct files to create the Jenkins job and to run it and to configure the commit hook to notify Jenkins.
The git plugin also checks out the exact commit and branch and then schedules a build – one of the additional requirements I have been given which it ALMOST does is to update the config.xml to represent what’s in the branch|commit that we will build against – thus as the developers move their build requirements forward and change their Jenkins job requirements our Jenkins job moves with it, and the devlopers can keep the job with their code and know that it is built as they require it to be.
Both of these hacks can be made to the git-plugin to meet our needs, and once we (AOL) have it in the new plugin (cicd-git?) we’ll find a way to release it back as open source.
The logic is that since the git plugin already receives the notifyCommit packet, and does most of what we require, that we can get it to take these next couple of steps toward making Jenkins hands off as far as Dev Ops is concerned. There is a gitlabs plugin that handles the “what if the repo doesn’t exist in Jenkins job configurations?” case – unfortunately it applies to github, and we are currently using bitbucket. Because that functionality has not been brought into the git plugin up to this point, I suspect it is a specialty case and a separate plugin might be better than trying to get git plugin to do everything to all users.
—doug
