- Place the template file in a relevant directory
Development guide for GitLab CI/CD templates
This document explains how to develop GitLab CI/CD templates.
Place the template file in a relevant directory
All template files reside in the
lib/gitlab/ci/templates directory, and are categorized by the following sub-directories:
|Sub-directroy||Content||Selectable in UI|
|Auto DevOps related jobs||Yes|
|Static site generators for GitLab Pages (for example Jekyll)||Yes|
|Security related jobs||Yes|
|Verify/testing related jobs||Yes|
|Common uses of the ||No|
The file must follow the
Verify it’s valid by pasting it into the CI lint tool at
Also, all templates must be named with the
A template might be dynamically included with the
include:template: keyword. If
you make a change to an existing template, you must make sure that it won’t break
CI/CD in existing projects.
Each CI/CD template must be tested in order to make sure that it’s safe to be published.
It’s always good practice to test the template in a minimal demo project. To do so, please follow the following steps:
- Create a public sample project on https://gitlab.com.
- Add a
.gitlab-ci.ymlto the project with the proposed template.
- Run pipelines and make sure that everything runs properly, in all possible cases (merge request pipelines, schedules, and so on).
- Link to the project in the description of the merge request that is adding a new template.
This is useful information for reviewers to make sure the template is safe to be merged.
Make sure the new template can be selected in UI
Templates located under some directories are also selectable in the New file UI. When you add a template into one of those directories, make sure that it correctly appears in the dropdown:
Write an RSpec test
You should write an RSpec test to make sure that pipeline jobs will be generated correctly:
- Add a test file at
- Test that pipeline jobs are properly created via
A template could contain malicious code. For example, a template that contains the
export shell command in a job
might accidentally expose project secret variables in a job log.
If you’re unsure if it’s secure or not, you need to ask security experts for cross-validation.