Lab 16 — Pipelines parent-enfant dynamiques

Un pipeline statique peut devenir coûteux quand il traite tous les cas de la même manière. Dans ce lab, vous introduisez une orchestration parent-enfant pour générer un plan d’exécution dynamique, piloté par un script versionné dans le dépôt.

Ce que vous allez apprendre

Concevoir une étape d’orchestration dans un pipeline CI
Générer dynamiquement un YAML enfant depuis un script shell
Déclencher un child pipeline avec trigger et artifact
Ajouter une logique contextuelle simple (branche par défaut vs autre branche)

Dans quel contexte ?

Ce pattern devient utile quand un pipeline doit s’adapter à des changements fréquents de périmètre. Un monolithe CI finit par lancer trop de jobs pour des modifications mineures.

Vous utiliserez cette approche quand :

différents services doivent déclencher des sous-pipelines spécialisés ;
vous voulez isoler la logique de décision dans un script maintenable ;
vous cherchez à réduire le coût CI sans perdre de contrôle.

Prérequis

Lab 15 — Matrices multi-versions terminé
Avoir lu Pipelines parent-enfant et Pipelines dynamiques

Point de départ

Basculez sur la branche du lab
Fenêtre de terminal
```
cd pipeline-craft
git checkout starter/lab-16
```
Vérifiez la structure existante

Le pipeline est déjà découpé et matriciel, mais pas encore dynamique.
Lancez une baseline
Fenêtre de terminal
```
git push origin starter/lab-16
```

Le problème

Le pipeline actuel exécute toujours la même séquence, même pour des cas simples. Vous allez introduire une orchestration pour produire un sous-plan plus ciblé.

L’exercice

Étape 1 — Ajouter un fichier d’orchestration CI

Créez ci/orchestration.yml
Ajoutez un job generate-child-pipeline
Publiez child-pipeline.yml en artifact

Indice : utilisez un expire_in court pour cet artifact temporaire.

👉 Vérifier votre solution (Étape 1)

1️⃣ Fichier `ci/orchestration.yml`

generate-child-pipeline:
   stage: orchestrate
   image: alpine:3.20
   before_script:
      - apk add --no-cache bash git
   script:
      - chmod +x scripts/generate-child-pipeline.sh
      - ./scripts/generate-child-pipeline.sh
   artifacts:
      paths:
         - child-pipeline.yml
      expire_in: 1 day

run-child-pipeline:
   stage: orchestrate
   needs:
      - generate-child-pipeline
   trigger:
      include:
         - artifact: child-pipeline.yml
            job: generate-child-pipeline
      strategy: depend
   rules:
      - if: $CI_PIPELINE_SOURCE == "push"
      - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Étape 2 — Générer dynamiquement le YAML enfant

Créez le script scripts/generate-child-pipeline.sh

Indice : ce fichier n’existe pas dans le starter, vous devez le créer.
Ajoutez une logique contextuelle

Exemple : ajouter un job supplémentaire si la branche vaut main.
Vérifiez que le script est exécutable
Fenêtre de terminal
```
chmod +x scripts/generate-child-pipeline.sh
```

👉 Vérifier votre solution (Étape 2)

1️⃣ Script `scripts/generate-child-pipeline.sh`

#!/usr/bin/env bash
set -euo pipefail

# Dynamic child pipeline used in Lab 16.
# It adapts jobs according to branch context.

cat > child-pipeline.yml <<'YAML'
stages:
   - verify

child-smoke:
   stage: verify
   image: alpine:3.20
   script:
      - echo "Smoke check in child pipeline"
YAML

if [[ "${CI_COMMIT_BRANCH:-}" == "${CI_DEFAULT_BRANCH:-}" ]]; then
   cat >> child-pipeline.yml <<'YAML'

child-default-branch-check:
   stage: verify
   image: alpine:3.20
   script:
      - echo "Extra checks on default branch"
YAML
fi

cat child-pipeline.yml

Étape 3 — Déclencher le child pipeline

Ajoutez un job run-child-pipeline
Utilisez trigger avec include artifact

Indice : gardez strategy: depend pour propager l’état du pipeline enfant.
Ajoutez ci/orchestration.yml dans les includes du pipeline racine

👉 Vérifier votre solution (Étape 3)

1️⃣ Orchestrateur racine mis à jour

Le pipeline racine ajoute un stage orchestrate et inclut le fichier d’orchestration.

stages:
   - lint
   - test
   - orchestrate
   - build
   - deploy

include:
   - local: ci/lint.yml
   - local: ci/test.yml
   - local: ci/build.yml
   - local: ci/deploy.yml
   - local: ci/orchestration.yml

Étape 4 — Valider puis pousser

Lint branch-aware
Fenêtre de terminal
```
 glab ci lint .gitlab-ci.yml
```

Commit

git add .gitlab-ci.yml ci/orchestration.yml scripts/generate-child-pipeline.sh
git commit -m "ci: add dynamic parent-child orchestration"
git push origin starter/lab-16

Vérifiez les deux niveaux de pipeline dans GitLab

👉 Vérifier votre solution (Étape 4)

1️⃣ Contrôles attendus

generate-child-pipeline produit bien child-pipeline.yml en artifact ;
run-child-pipeline déclenche le child pipeline via trigger.include.artifact ;
le parent attend le résultat enfant (strategy: depend) ;
un job supplémentaire apparaît dans le child pipeline sur la branche par défaut.

Le fichier complet

📄 Voir le fichier .gitlab-ci.yml complet

stages:
   - lint
   - test
   - orchestrate
   - build
   - deploy

workflow:
   rules:
      - if: $CI_PIPELINE_SOURCE == "push"
      - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      - if: $CI_COMMIT_TAG

default:
   interruptible: true

variables:
   PIP_CACHE_DIR: "$CI_PROJECT_DIR/.pip-cache"

include:
   - local: ci/lint.yml
   - local: ci/test.yml
   - local: ci/build.yml
   - local: ci/deploy.yml
   - local: ci/orchestration.yml

📄 Voir le fichier ci/orchestration.yml complet

generate-child-pipeline:
   stage: orchestrate
   image: alpine:3.20
   before_script:
      - apk add --no-cache bash git
   script:
      - chmod +x scripts/generate-child-pipeline.sh
      - ./scripts/generate-child-pipeline.sh
   artifacts:
      paths:
         - child-pipeline.yml
      expire_in: 1 day

run-child-pipeline:
   stage: orchestrate
   needs:
      - generate-child-pipeline
   trigger:
      include:
         - artifact: child-pipeline.yml
            job: generate-child-pipeline
      strategy: depend
   rules:
      - if: $CI_PIPELINE_SOURCE == "push"
      - if: $CI_PIPELINE_SOURCE == "merge_request_event"

📄 Voir le fichier scripts/generate-child-pipeline.sh complet

#!/usr/bin/env bash
set -euo pipefail

# Dynamic child pipeline used in Lab 16.
# It adapts jobs according to branch context.

cat > child-pipeline.yml <<'YAML'
stages:
   - verify

child-smoke:
   stage: verify
   image: alpine:3.20
   script:
      - echo "Smoke check in child pipeline"
YAML

if [[ "${CI_COMMIT_BRANCH:-}" == "${CI_DEFAULT_BRANCH:-}" ]]; then
   cat >> child-pipeline.yml <<'YAML'

child-default-branch-check:
   stage: verify
   image: alpine:3.20
   script:
      - echo "Extra checks on default branch"
YAML
fi

cat child-pipeline.yml

Vérification

ci/orchestration.yml existe et est inclus dans le pipeline racine
child-pipeline.yml est généré puis consommé via artifact
Le child pipeline se déclenche correctement
Le comportement varie selon le contexte défini

Pièges fréquents

Un child pipeline échoue souvent pour une raison simple : YAML généré invalide. Ajoutez un cat child-pipeline.yml dans le job de génération pour faciliter le debug.

Autre point important : sans strategy: depend, le parent peut se terminer sans attendre le résultat réel du child.

À retenir

Le parent-enfant sépare orchestration et exécution métier
Un script versionné permet une logique dynamique contrôlée
Les artifacts servent de transport de configuration entre jobs
Un pipeline dynamique reste auditable s’il est lisible et traçable

Prochaines étapes

Lab 17 — Workflows branches et MR Appliquer des règles workflow avancées selon le type de pipeline

Guide : parent-enfant Approfondir le modèle de déclenchement des child pipelines

Guide : pipelines dynamiques Approfondir la génération conditionnelle de YAML