Triggering Other GitLab Pipelines in Multi-Project Builds

When using microservices or managing multiple interdependent projects, updating one project often necessitates redeploying others. Managing these co-dependencies in in your pipelines can negate having to remember to do these updates manually (or worse, forget to, then wonder why on the next deploy it breaks!).

As an example, we have an internal documentation platform built with Gatsby. Amongst other things this static site, relies on a repository of CloudFormation snippets as content (it renders them along with their readmes as docs). Each time this repository updated, we need to trigger a rebuild of the documentation site to keep the content current.

This scenario is of course not limited to documentation; we have similar needs with Docker images and internal npm packages, where updates in one area automatically lead to rebuilds or updates downstream.

Automating with GitLab Pipeline Triggers

To automate this process, we use GitLab’s pipeline triggers. This feature allows us to initiate rebuilds in other projects as soon as changes are pushed to a repository. Here’s a simple snippet from our GitLab CI configuration that illustrates setting up such a trigger:

trigger_job:
  trigger:
    project: group-name/project-name

This configuration ensures that any update made to the specified project immediately initiates the necessary actions in related projects, ensuring all components are up-to-date.

This is just a simple example, the GitLab documentation on downstream pipelines, provides more ideas and advanced examples.

About James Babington

A cloud architect and engineer with a wealth of experience across AWS, web development, and security, James enjoys writing about the technical challenges and solutions he's encountered, but most of all he loves it when a plan comes together and it all just works.