Like I’ve mentioned in my last blog post, we use GitLab pipelines for packaging. We have a lot of software, like Icinga, Icingaweb and its various modules, which we want to build across multiple different operating systems. This results in a huge number of jobs and pipelines, doing very similar stuff. We have a lot of code repetition, and this is bad – code repetition means higher code maintenance , and it invites bugs. In my last blogpost, I discussed using jsonnet to fix this issue – this time I’ll show you how to setup a simple GitLab CI/CD template library.
Job templates
At Icinga, we have a lot of jobs in our GitLab pipelines, like building software packages, testing and uploading them. For now, each of the jobs is described in every single project across our GitLab – each project has it’s own .gitlab-ci.yml file containing the full text of the job. How would I go about reducing repetition in our projects? We need a job template – a version of the job which can be applied to all of the projects, with no specific information concering a certain project. I created a simple job template for the example I’m presenting to you today. It’s very simple to set up, we only need a new .yml file containing our generic job, which we then can import into our projects. 
I created my job template in a special project containing nothing but job templates. You can add templates to a project and use them locally as well, though. Here is how you’d include this simple job in a different project.
Now let’s add a variable to our job template, so we can see how our job template can be adjusted for varying projects. For that, we need to change the visibility of the job in our job template by adding a dot in front of its name:
As you can see, I’ve added the variable MESSAGE to our job template. This variable will be overwritten in our other project, where we will have multiple jobs executing the script from our job template, every time with a different value for MESSAGE.
And this is how you use job templates in Gitlab. From this point on, much more complex structures could be built, but at the heart of it remains the spirit of not trying to repeat yourself too often, which means less work, which means more time to build more complex CI/CD systems!
