A shared library lives in its own GitLab project, consumed by 5 downstream application projects. How would you trigger those downstream pipelines automatically when the library changes?

Use GitLab's multi-project pipeline triggers: add a trigger: job in the shared library's pipeline (typically on its default branch) that triggers each downstream project's pipeline, using a trigger token or the built-in trigger keyword targeting the downstream project — this creates a real cross-project pipeline relationship, visible in GitLab's pipeline graph, rather than relying on the downstream projects independently polling or manually re-running.

The goal here is closing a feedback loop that would otherwise be invisible: without an explicit trigger relationship, a downstream project's pipeline only reflects the shared library version pinned at whatever time its own dependencies were last resolved — a breaking change in the library wouldn't be caught until a downstream project happens to update its dependency and run its own pipeline, which could be days or weeks later.

• A change to the shared library's default branch should automatically trigger each downstream project's pipeline.
• The downstream pipeline should test against the library's new version specifically, not just its previously pinned version.
• The relationship should be visible/traceable — you should be able to see which downstream pipeline run was triggered by which library change.

A trigger job in the library's pipeline targets each downstream project:

trigger-downstream-app-1:
  stage: notify-downstream
  trigger:
    project: my-group/app-1
    branch: main
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

This runs as part of the library's own pipeline (gated to only fire on its default branch, not every feature branch) and triggers a pipeline in the downstream project — GitLab represents this as a real multi-project pipeline relationship, viewable as a connected graph in the UI, not just an independent, unrelated pipeline run.

The downstream pipeline needs to actually pull the new library version, not just be triggered: triggering alone doesn't change what version the downstream project builds against — the downstream pipeline (or a specific job within it) needs to be configured to fetch the library's latest version when triggered this way (e.g., via a package registry lookup, or a dedicated CI variable indicating "use latest" for this specific triggered run), rather than using its normally-pinned version.

Scale this via a shared trigger configuration rather than duplicating 5 separate trigger jobs, if the downstream project list is expected to grow — a small script generating the list of trigger jobs (or a loop, depending on your GitLab version's YAML capabilities) reduces the maintenance burden of manually keeping 5 (or more, over time) trigger job definitions in sync.

Consider whether this should be a hard gate or just an informational signal: a downstream pipeline failing because of a new library version could either just notify (create visibility that something broke, without blocking the library's own release) or actually block the library from being considered "safe to release" until all downstream pipelines pass — this is a real design decision depending on how tightly coupled you want the library's release process to be to its consumers' pipelines.

Multi-project triggers add real coupling between the library and downstream projects' pipelines — a library change now has a wider blast radius (triggering 5 pipelines, potentially consuming meaningfully more CI resources) than a self-contained pipeline, and debugging a triggered downstream failure requires understanding the cross-project relationship, not just reading one project's pipeline in isolation.

• GitLab's multi-project pipeline triggers create a real, visible cross-project pipeline relationship, closing the feedback loop between a shared library's changes and its downstream consumers.
• Triggering alone doesn't change what version a downstream pipeline tests against — the downstream pipeline needs explicit configuration to pull the library's new version when triggered this way.
• Decide deliberately whether downstream pipeline failures should just inform (visibility) or actually gate the library's own release — this is a real coupling decision, not a default.
• This adds real CI resource cost and cross-project debugging complexity, worth it specifically for catching breaking changes early rather than discovering them much later.

• GitLab Docs: Multi-project pipelines