If you are coming from the Jenkins world, you may be wondering whether GitLab pipelines can accept parameters. They can and I’ll demonstrate below how to define and run parameterized pipelines in GitLab. If you later find this article useful take a look at the disclaimer for information on how to thank me.
From Jenkinsfile to gitlab-ci.yml
If you embrace configuration as code principle (as you should) you code your Jenkins pipelines in Jenkinsfile. Jenkins declarative pipeline’s parameters directive allows to specify pipeline’s parameters which pipeline’s customer may need to fill while running the pipelines. I’ve already covered how to migrate from Jenkins to GitLab. If you migrate your automation pipelines from Jenkins to GitLab, you may rightly ask if GitLab pipelines can accept parameters. Let’s see how to define parameters in GitLab pipelines. Those parameters will reside in GitLab’s
Jenkinsfile equivalent i.e.
Defining GitLab Parameterized Pipelines
gitlab-ci.yaml defines parameters for the GitLab pipeline using the
variables: DOCKER_VERSION: value: "20.10.21" options: - "20.10.21" - "20.10.22" - "20.10.23" description: "Docker daemon version"
As you can see, the pipeline later references the value of the
DOCKER_VERSION variable. This value influences the version of docker daemon and client used during the pipeline’s execution.
Feel free to fork the project and play along with it.
See more information about defining pipeline’s variables in GitLab docs.
Running GitLab Parameterized Pipelines:
Sometimes, other pipelines would like to run the pipeline in an automatic manner. For that you can use GitLab’s API.
You can also use GitLab’s CLI for running the pipeline:
glab ci run -b main --variables key1:val1,key2:val2
Differences from Standard GitLab CI/CD Pipelines
Note, that GitLab parameterized pipelines are different from standard GitLab CI/CD pipelines, which typically run by default on merge to default branch (e.g.
main) or merge request events. Whereas, these pipelines usually resemble Jenkins automation pipelines, which you run manually only.
To control when the job of the sample pipeline above runs I used below block in its
rules: - if: $CI_PIPELINE_SOURCE == "schedule" - if: $CI_PIPELINE_SOURCE == "web" - if: $CI_PIPELINE_SOURCE == "api" - if: $CI_PIPELINE_SOURCE == "trigger" - if: $CI_PIPELINE_SOURCE != "push" when: never - if: $CI_PIPELINE_SOURCE != "merge_request_event" when: never
If your pipeline has multiple jobs, you’d need to put the above block in all its jobs, because
rules keyword applies to jobs only.
That covers the basics of defining and running parameterized pipelines in GitLab. As always, feel free to share this article with others who might find it useful.
If you found this article helpful, please refer to the disclaimer section for ways to show your appreciation.
You may also find below articles interesting:
- Auto Tag Releases with Semantic Versions
- GitLab Self-Hosted Runners Demo
- Clone Private Repositories in GitLab Pipelines