Quite often different components in a project rely on each other in a way that requires your pipeline to interact with other component pipelines. Not only large software development projects might be customers to such use cases. Using GitLab CI runners to execute infrastructure automation tasks is also a great use case. Or the combination of both, which I faced. Upon the successful build process of the project only, we want to run a pipeline in a different GitLab repository containing the infrastructure automation deploying the release to the target environments.

As I recently figured out, using GitLab CI is a great advantage in such a situation as it provides great flexibility to set up such a scenario.

1adb850ebe02d70ce068744b1b8694c5.png

Here are the required steps:

trigger-deployment:
  stage: build
  only:
    refs:
      - tags
    variables:
      - $CI_COMMIT_TAG =~ /^[Rr]elease-.*/
  trigger:
    project: infra-grp/deplyoment-scripts
    branch: release-to-integration
    strategy: depend

971cd59c989139ba4bc0999bb1d3001a.png

In project A, the pipeline file, e.g. .gitlab-ci.yml, is extended with a job that reacts on a given pattern of tag names - in our case anything that starts with “release-“ or “Release-“ as defined by the RegExp /^[Rr]elease-.*/. (Yes, learning RegExp is still helpful. I can only recommend digging into it. It has been proven useful to me in many projects and definitely is well-invested time for every Software Engineer, Developer, DevOps Engineer or whatever title the industry comes up with ;-).

The trigger: block then references the project and the branch we want to run.

d259cafe9a7ced8f1bb10a71e0f6dda5.png

You should pay some special attention to trigger:strategy as this can force the job to wait for the downstream pipeline to complete before it is marked as success (which is opposed to the default that acts more like a “fire trigger and forget”). But keep in mind that it also turns the pipeline into being more sequential than parallel and thus takes more time to complete.

Visit the GitLab documentation for triggers for all details.

Do you want to read more posts like this or have questions? Feel free to send me a question, comment or request via email or on Mastodon.