Image from Simpsons Mathematics
Configuring the Jenkins Master on Boot with Groovy
One of the greatest strengths of Jenkins is it’s ability to do almost anything. This comes from it’s extremely customizable nature. I think of it as a scheduler that can do any given task on any given trigger with enough configuration. What we are building specifically though is a system to build, test, and deploy our piece of custom software that most likely is at least a little bit different than anything else out there requiring the same tasks. We will need to use Jenkins’ ultra powerful customization toolkit, but do it in a way that strives to be:
Deterministic: Given a set of inputs, there should be only one output. If that output is not as we expect, there is a problem that we should spend time fixing. ie: removing “flaky” tests that fail for “no reason”.
Reliable: The system should have high availability to the users who depend on it. Having a system that is sometimes down and sometimes up does not encourage teams to inject automated builds into their workflows.
Repeatable: This system should be able to be recreated without persistent data from the repo.
Agile: The system should evolve to meet the needs of it’s consumers in a sustainable way. If one team’s jobs or configs are breaking another team’s pipelines, it is a good indication that it is time to split the monolith into two independent systems.
Scalable: As the system becomes more popular, more people are going to utilize it. When this happens, it’s critical to be able to support the increased capacity in not only job runners, but also collaboration from more teams.
Luckily we can treat the code that configures the system in the same way we treat the code the builds and runs the system :)
Intro to the Jenkins init system
Jenkins has a not-much-talked about feature that I have yet to see much information on. It is the Jenkins Groovy Init system and really the only documentation I have been able to find are two articles on the Jenkins wiki: https://wiki.jenkins.io/display/JENKINS/Post-initialization+script
which points to this: https://wiki.jenkins.io/display/JENKINS/Configuring+Jenkins+upon+start+up
Not super impressive documentation considering how powerful this mechanism is. Using this init system you are able to configure any aspect of the master that you are able to using “Manage Jenkins”. This includes (but is not limited to):
- The URL and name of this instance
- Authentication and security settings
- Secrets in the credential store
- Global plugin configuration
- Global tool configuration
- Adding and removing nodes
- Creation of jobs (though we’ll only use it to create one special job)
The Groovy Script Console
Not only does it support configuring so much of the system, it has a direct REPL like environment to code in. This is called the “Script Console” (available at http://localhost:8080/script on our instance) and can be considered a shell into the Jenkins system. This shell has the same abilities of the init system’s shell so it makes for super quick and easy development of the scripts that we will use.
Jenkins Groovy Hello World
Let’s kill two stones with one bird. We will do a quick little Hello World that will introduce you to bot the syntax of groovy as well as how to use the script console.
- Stand up your development Jenkins (
cd deploy/master && docker-compose up -d)
- Browse to the script console at http://localhost:8080/script
- Enter the following into the box in front of you:
- Browse back to the main Jenkins interface
- Check out the cool message for all the users of your system to see. I bet your boss will love it!
Nothing too crazy, but this should give you a good idea of how we are going to
configure our master to build our particular brand of software. Inside Old Mr.
Jenkins is just a series of objects (I think of them as his organs) that we can
grab and squeeze and modify to fit our needs. I hope Janky is ready to play