Categories
CI/CD DevOps

GitLab Parameterized Pipelines

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.

Table Of Contents
  1. From Jenkinsfile to gitlab-ci.yml
  2. Defining GitLab Parameterized Pipelines
  3. Running GitLab Parameterized Pipelines:
  4. Differences from Standard GitLab CI/CD Pipelines
  5. Summary

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. gitlab-ci.yml.

Defining GitLab Parameterized Pipelines

To see a working GitLab parameterized pipeline, navigate to a sample project from my GitLab. My previous post on GitLab CI for Go apps uses the same sample GitLab project.

Its gitlab-ci.yaml defines parameters for the GitLab pipeline using the variables keyword:

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:

Navigate to Run pipeline dialog in sample GitLab parameterized pipelines demo project to see how to run the pipeline via GitLab’s UI.

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 gitlab-ci.yaml:

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.

Summary

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:

Recommended Gitlab books on Amazon.