Exercice 01 : Contrôler l'exécution avec les rules

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Utiliser rules: if: pour conditionner un job selon la branche ou la source
✅ Maîtriser les valeurs de when: : never, always, on_success, manual
✅ Déclencher un job uniquement si certains fichiers sont modifiés avec rules: changes:
✅ Comprendre pourquoi rules: remplace avantageusement only: / except:

Durée estimée : 20 minutes

Difficulté : ⭐⭐⭐☆☆ (Intermédiaire)

Prérequis :

Modules GitLab CI Débutant complétés
Notions de branches Git

📖 Contexte

only: et except: sont les anciennes façons de contrôler l'exécution des jobs. Elles sont simples mais limitées. rules: est leur remplaçant : plus expressif, il permet de combiner des conditions sur la branche, la source du pipeline, les fichiers modifiés, des variables... Depuis GitLab 12.3, rules: est la méthode recommandée.

📋 Énoncé

Créez un pipeline avec plusieurs jobs dont l'exécution est conditionnée par la branche, la source du pipeline, et les fichiers modifiés. Un job de déploiement en production ne doit s'exécuter que manuellement depuis main.

🧭 Déroulement de l'exercice

Tâche 1 : Limiter un job à la branche main

Créez un job deploy-prod qui ne s'exécute que sur la branche main. Utilisez rules: if: avec la variable $CI_COMMIT_BRANCH.

Indice :
`yaml
deploy-prod:
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: on_success
- when: never
`
La liste rules: est évaluée dans l'ordre. La première règle qui correspond s'applique. when: never en dernière règle exclut le job pour tous les autres cas.

Vérification : Sur une branche feature/test, le job deploy-prod n'apparaît pas dans le pipeline.

Tâche 2 : Rendre le déploiement en production manuel

Modifiez deploy-prod pour qu'il soit déclenché manuellement (bouton play) sur main, plutôt qu'automatiquement.

Indice : Remplacez when: on_success par when: manual. Le job apparaît dans le pipeline avec un bouton ▶ (play) et nécessite une action humaine pour démarrer.

Vérification : Sur main, le job deploy-prod apparaît avec un bouton play et ne s'exécute pas automatiquement.

Tâche 3 : Déclencher sur modification de fichiers

Créez un job build-frontend qui ne s'exécute que si des fichiers dans src/ ou public/ ont été modifiés. Utilisez rules: changes:.

Indice :
`yaml
build-frontend:
rules:
- changes:
- src/**/*
- public/**/*
when: on_success
- when: never
`
changes: compare les fichiers modifiés dans le commit courant. Si aucun fichier de la liste n'est modifié, la règle ne s'applique pas.

Vérification : Faites un commit en modifiant uniquement README.md : build-frontend ne s'exécute pas. Modifiez un fichier dans src/ : le job s'exécute.

Tâche 4 : Exclure les pipelines de merge request

Créez un job notify-slack qui ne s'exécute jamais sur les pipelines de merge request (source merge_request_event).

Indice :
`yaml
notify-slack:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
when: never
- when: on_success
`
L'ordre des règles est crucial : la règle d'exclusion doit être en premier.

Vérification : Le job notify-slack n'apparaît pas dans les pipelines de MR.

Tâche 5 : Combiner conditions if et changes

Créez un job build-and-test qui s'exécute uniquement sur main ET si package.json a été modifié.

Indice : On peut combiner if: et changes: dans la même règle. Les deux conditions doivent être vraies simultanément :
`yaml
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
changes:
- package.json
when: on_success
- when: never
`

Vérification : Le job ne s'exécute que sur main avec package.json modifié.

🗂️ Mini-Projet : Pipeline avec rules avancées

Checkpoints de validation :

deploy-prod n'est visible que sur main avec un bouton play
build-frontend est ignoré si aucun fichier src/ n'est modifié
notify-slack est absent des pipelines de merge request
Les logs du CI Lint valident toutes les rules:
Aucune utilisation de only: ou except: dans le fichier

Exercice 01 : Contrôler l'exécution avec les rules

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Utiliser rules: if: pour conditionner un job selon la branche ou la source
✅ Maîtriser les valeurs de when: : never, always, on_success, manual
✅ Déclencher un job uniquement si certains fichiers sont modifiés avec rules: changes:
✅ Comprendre pourquoi rules: remplace avantageusement only: / except:

Durée estimée : 20 minutes

Difficulté : ⭐⭐⭐☆☆ (Intermédiaire)

Prérequis :

Modules GitLab CI Débutant complétés
Notions de branches Git

📖 Contexte

📋 Énoncé

🧭 Déroulement de l'exercice

Tâche 1 : Limiter un job à la branche main

Créez un job deploy-prod qui ne s'exécute que sur la branche main. Utilisez rules: if: avec la variable $CI_COMMIT_BRANCH.

Indice :
`yaml
deploy-prod:
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: on_success
- when: never
`
La liste rules: est évaluée dans l'ordre. La première règle qui correspond s'applique. when: never en dernière règle exclut le job pour tous les autres cas.

Vérification : Sur une branche feature/test, le job deploy-prod n'apparaît pas dans le pipeline.

Tâche 2 : Rendre le déploiement en production manuel

Modifiez deploy-prod pour qu'il soit déclenché manuellement (bouton play) sur main, plutôt qu'automatiquement.

Indice : Remplacez when: on_success par when: manual. Le job apparaît dans le pipeline avec un bouton ▶ (play) et nécessite une action humaine pour démarrer.

Vérification : Sur main, le job deploy-prod apparaît avec un bouton play et ne s'exécute pas automatiquement.

Tâche 3 : Déclencher sur modification de fichiers

Créez un job build-frontend qui ne s'exécute que si des fichiers dans src/ ou public/ ont été modifiés. Utilisez rules: changes:.

Indice :
`yaml
build-frontend:
rules:
- changes:
- src/**/*
- public/**/*
when: on_success
- when: never
`
changes: compare les fichiers modifiés dans le commit courant. Si aucun fichier de la liste n'est modifié, la règle ne s'applique pas.

Vérification : Faites un commit en modifiant uniquement README.md : build-frontend ne s'exécute pas. Modifiez un fichier dans src/ : le job s'exécute.

Tâche 4 : Exclure les pipelines de merge request

Créez un job notify-slack qui ne s'exécute jamais sur les pipelines de merge request (source merge_request_event).

Indice :
`yaml
notify-slack:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
when: never
- when: on_success
`
L'ordre des règles est crucial : la règle d'exclusion doit être en premier.

Vérification : Le job notify-slack n'apparaît pas dans les pipelines de MR.

Tâche 5 : Combiner conditions if et changes

Créez un job build-and-test qui s'exécute uniquement sur main ET si package.json a été modifié.

Indice : On peut combiner if: et changes: dans la même règle. Les deux conditions doivent être vraies simultanément :
`yaml
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
changes:
- package.json
when: on_success
- when: never
`

Vérification : Le job ne s'exécute que sur main avec package.json modifié.

🗂️ Mini-Projet : Pipeline avec rules avancées

Checkpoints de validation :

deploy-prod n'est visible que sur main avec un bouton play
build-frontend est ignoré si aucun fichier src/ n'est modifié
notify-slack est absent des pipelines de merge request
Les logs du CI Lint valident toutes les rules:
Aucune utilisation de only: ou except: dans le fichier