Module 4 Lesson 1: Multi-Project Pipelines

In a microservice architecture, one "Push" might need to trigger several other projects.

• Scenario: You update the "Auth Library" in project-a.
• The Need: Now, the "Payment Service" in project-b must automatically rebuild to use the new library.

This is called a Downstream Pipeline.

1. The trigger Keyword

To start a pipeline in a different project, use the trigger keyword.

trigger-payment-build:
  stage: deploy
  trigger:
    project: my-company/payment-service  # The path to the other repo
    branch: main                         # Which branch to start?

---

2. Passing Variables to Downstream

You can send instructions to the other project using variables.

trigger-payment-build:
  variables:
    SOURCE_PROJECT: $CI_PROJECT_NAME
    NEW_VERSION: $CI_COMMIT_TAG
  trigger: my-company/payment-service

---

3. "Upstream" vs "Downstream"

• Upstream: The project that starts the process (The Triggerer).
• Downstream: The project that responds to the call (The Triggered).

In GitLab, the "Upstream" pipeline can wait for the "Downstream" one to finish before marking itself as "Success" by using strategy: depend.

Visualizing Multi-Project Pipeline Flow

graph LR
    subgraph "Project Alpha (Upstream)"
        A1[Code Push] --> A2[Build]
        A2 --> A3[Test]
        A3 --> A4[Trigger Job]
    end
    
    A4 -->|trigger| B1
    
    subgraph "Project Beta (Downstream)"
        B1[Triggered Build] --> B2[Run Tests]
        B2 --> B3[Deploy]
    end
    
    B3 -.->|strategy: depend| A4
    A4 --> A5[Mark Success/Fail]

---

4. Why Use This?

1. Isolation: Every team keeps their own .gitlab-ci.yml. They don't have to merge their code into one massive "Monorepo."
2. Versioning: You can trigger the downstream project to only run tests against your "Alpha" version, keeping the "Stable" version safe.
3. Complex Deployments: Use one "Gateway" project to deploy 10 different apps at the same time.

---

Exercise: The Chain Reaction

1. Create two separate projects in GitLab: Project Alpha and Project Beta.
2. In Project Alpha, create a job that triggers a pipeline in Project Beta.
3. Add strategy: depend to the trigger job.
4. In Project Beta, add a simple test job.
5. Run Alpha's pipeline. Check the graph. Do you see the "Downstream" pipeline listed there?
6. If Project Beta fails, does Project Alpha also show as "Failed"? (Check the strategy effect).

---

Summary

Multi-project pipelines turn your individual automation scripts into a "System of Systems." By mastering triggers, you can orchestrate complex releases that involve multiple teams and repositories across your whole company.

Next Lesson: Internal organization: Parents and Child Pipelines.