Lab 17 — Workflows branches et merge requests

Un pipeline bien construit peut rester inefficace si son workflow est mal défini. Vous obtenez alors des pipelines en double, des runs inutiles, et des comportements incohérents entre MR et branches. Dans ce lab, vous corrigez ce pilotage global.

Ce que vous allez apprendre

Construire un bloc workflow: rules lisible et priorisé
Différencier contexte MR, branche simple, branche par défaut et tag
Éviter les doublons via $CI_OPEN_MERGE_REQUESTS
Ajuster les règles de déploiement selon le contexte d’exécution

Dans quel contexte ?

Dans les équipes actives, un même commit peut déclencher plusieurs pipelines si le workflow n’est pas clairement défini. Cela consomme des minutes CI et brouille la lecture des statuts dans les merge requests.

Ce lab répond à des cas fréquents :

pipelines branch + MR en parallèle pour le même changement ;
déploiements déclenchés dans un mauvais contexte ;
manque de clarté sur les flux tag/release.

Prérequis

Lab 16 — Pipelines parent-enfant dynamiques terminé
Avoir lu Workflows CI/CD

Point de départ

Basculez sur la branche du lab
Fenêtre de terminal
```
cd pipeline-craft
git checkout starter/lab-17
```
Ouvrez .gitlab-ci.yml

Vérifiez le bloc workflow actuel.
Lancez un run baseline
Fenêtre de terminal
```
git push origin starter/lab-17
```

Le problème

Les règles workflow actuelles ne couvrent pas proprement tous les cas. Vous devez prioriser les conditions pour obtenir un flux explicite et non ambigu.

L’exercice

Étape 1 — Poser un workflow MR-first

Placez d’abord le cas MR

Indice : ce cas doit être évalué avant les règles plus génériques sur les branches.
Ajoutez un filtre anti-duplication

Indice : une règle when: never bien placée évite les doublons branch/MR.
Gardez ensuite les cas branche par défaut, branche simple, et tag

👉 Vérifier votre solution (Étape 1)

1️⃣ Bloc `workflow: rules` attendu

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_BRANCH
    - if: $CI_COMMIT_TAG

Ce workflow donne la priorité aux pipelines MR et évite un pipeline branch redondant quand une MR est déjà ouverte.

Étape 2 — Aligner les jobs de déploiement

Vérifiez les rules de deploy-staging et deploy-production
Ajoutez les règles manquantes liées au contexte MR train et release tag
Évitez les règles contradictoires entre workflow global et jobs

👉 Vérifier votre solution (Étape 2)

1️⃣ Règles de déploiement attendues dans `ci/deploy.yml`

deploy-staging:
  stage: deploy
  image: alpine:3.20
  script:
    - echo "Deploying $CI_COMMIT_SHORT_SHA to staging..."
    - ./scripts/deploy-demo.sh staging
  rules:
    - if: $CI_MERGE_REQUEST_EVENT_TYPE == "merge_train"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-production:
  stage: deploy
  image: alpine:3.20
  script:
    - echo "Deploying $CI_COMMIT_SHORT_SHA to production..."
    - ./scripts/deploy-demo.sh production
  rules:
    - if: $CI_COMMIT_TAG
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

Étape 3 — Valider puis pousser

Validation lint
Fenêtre de terminal
```
glab ci lint .gitlab-ci.yml
```

Commit et push

git add .gitlab-ci.yml ci/deploy.yml
git commit -m "ci: implement advanced workflow rules"
git push origin starter/lab-17

Vérifiez les déclenchements sur push et MR

👉 Vérifier votre solution (Étape 3)

1️⃣ Contrôles attendus

une MR déclenche un pipeline MR dédié ;
un push sur une branche avec MR ouverte ne déclenche pas de pipeline branch en plus ;
un tag peut déclencher le flux de production ;
les règles de déploiement restent cohérentes avec le workflow global.

Le fichier complet

📄 Voir le fichier .gitlab-ci.yml complet

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

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_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/orchestration.yml
  - local: ci/build.yml
  - local: ci/deploy.yml

📄 Voir le fichier ci/deploy.yml complet

deploy-staging:
  stage: deploy
  image: alpine:3.20
  script:
    - echo "Deploying $CI_COMMIT_SHORT_SHA to staging..."
    - ./scripts/deploy-demo.sh staging
  rules:
    - if: $CI_MERGE_REQUEST_EVENT_TYPE == "merge_train"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-production:
  stage: deploy
  image: alpine:3.20
  script:
    - echo "Deploying $CI_COMMIT_SHORT_SHA to production..."
    - ./scripts/deploy-demo.sh production
  rules:
    - if: $CI_COMMIT_TAG
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

Vérification

Le pipeline MR passe par la règle dédiée
Un commit sur branche avec MR ouverte ne crée pas de pipeline branch inutile
Les tags déclenchent le flux release attendu
Les déploiements suivent les contextes prévus

Pièges fréquents

Dans workflow: rules, l’ordre est critique : la première règle qui matche décide. Une règle générale placée trop tôt peut court-circuiter les cas spécifiques.

Autre piège : corriger uniquement les règles de job sans corriger le workflow global.

À retenir

Le workflow est le garde-barrière principal de votre CI
Un design MR-first réduit bruit et coûts CI
Les règles doivent être explicites et ordonnées
Le comportement release doit rester prédictible

Prochaines étapes

Lab 18 — Fiabilité et robustesse Rendre les jobs résilients aux erreurs transitoires

Guide : workflows Approfondir les patterns de workflow GitLab CI

Guide : déclencheurs Réviser les sources de pipelines et leurs effets