Module 4 Lesson 2: Parent and Child Pipelines

If your repository has multiple applications (a Monorepo), your .gitlab-ci.yml will eventually reach 2,000 lines. It becomes impossible to read. Child Pipelines allow you to "Outsource" parts of the logic to different files.

1. The "Monorepo" Challenge

Imagine a folder structure like this:

• /frontend
• /backend
• /docs

You don't want the "Docs" pipeline to run every time you fix a bug in the "Backend."

---

2. Triggering a Local File

In your main .gitlab-ci.yml (The Parent), you trigger a specific YAML file (The Child).

# parent .gitlab-ci.yml
frontend-pipeline:
  trigger:
    include: frontend/.gitlab-ci.yml
    strategy: depend
  rules:
    - changes:
        - frontend/**/*

---

3. Benefits of Child Pipelines

1. Speed: Only the relevant children start. Your project sidebar stays clean of irrelevant jobs.
2. Organization: The Frontend team only manages their own YAML file. They don't have to touch the "Master" file.
3. Independence: Child pipelines can have their own stages. You aren't limited to the global stages of the parent.

---

4. Dynamic Pipeline Generation (Advanced)

Did you know GitLab can Write a YAML file and then run it?

1. Stage 1 (Generate): A Python script looks at your files and writes a custom generated-ci.yml.
2. Stage 2 (Trigger): GitLab triggers that new file as a child.

• Scenario: If you have 100 microservices in one folder, you can generate a pipeline that only builds the 5 that actually changed.

---

Exercise: The Monorepo split

1. Create a project with two folders: app-1 and app-2.
2. Inside each folder, create a simple .gitlab-ci.yml.
3. In the root folder, create a Parent YAML that uses the include and trigger keywords.
4. Commit a change ONLY to app-1. Did the app-2 pipeline start?
5. Why is this better for a large team than having one giant file?
6. Research: What is the maximum depth of a Parent/Child pipeline? (Can a child have its own child?)

---

Summary

Parent/Child pipelines are the "Secret Weapon" for scaling DevOps. They allow you to maintain "Micro-services" inside a "Macro-repo," keeping your automation logic modular, fast, and easy to debug.

Next Lesson: Intelligence in order: The 'needs' keyword (DAGs).