Exercice 04 : Contrôler l'exécution avec les conditions if:

🎯 Objectifs

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

✅ Limiter un job à une branche spécifique avec if: github.ref == 'refs/heads/main'
✅ Différencier le comportement selon github.event_name
✅ Exécuter un step de nettoyage uniquement en cas d'échec avec failure()
✅ Ignorer un pipeline via [skip ci] dans le message de commit

Durée estimée : 20 min | Difficulté : ⭐⭐☆☆☆

📖 Contexte

Par défaut, tous les jobs et steps d'un workflow s'exécutent si les précédents réussissent. Les conditions if: permettent de contrôler finement l'exécution : déployer uniquement sur main, envoyer une notification seulement en cas d'échec, ignorer les commits de documentation, etc.

GitHub met à disposition des contextes (github, env, secrets) et des fonctions (success(), failure(), always(), contains()) utilisables dans les conditions.

📋 Énoncé

Vous allez créer un workflow qui démontre quatre types de conditions : limitation par branche, par événement, par statut, et par message de commit.

Résultat attendu :

Le job deploy ne s'exécute que sur la branche main
Un step de notification s'exécute uniquement si le job échoue
Un push avec [skip ci] dans le message ne déclenche rien

🧭 Déroulement

Tâche 1 : Conditionner un job sur la branche

Créez un workflow avec un job deploy qui ne s'exécute que sur la branche main. Testez en poussant sur une branche feature : le job doit être sauté.

Indice :
`yaml
deploy:
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main'
steps:
- run: echo "Déploiement sur production !"
`
Sur une branche feature/x, le job apparaîtra comme "skipped" (gris) dans l'interface.

Vérification : Sur feature/test, le job deploy est affiché comme ignoré (icône grise).

Tâche 2 : Conditionner sur l'événement déclencheur

Ajoutez un step qui affiche un message différent selon que le workflow est déclenché par un push ou une pull_request.

Indice :
`yaml
- name: Message pour push
if: github.event_name == 'push'
run: echo "Déclenché par un push direct"

- name: Message pour PR
if: github.event_name == 'pull_request'
run: echo "Déclenché par une Pull Request"
`

Vérification : En ouvrant une PR, seul le step "Message pour PR" s'exécute.

Tâche 3 : Utiliser failure() pour les notifications

Ajoutez un step de "notification d'erreur" qui ne s'exécute que si un step précédent du même job a échoué. Forcez un échec temporairement pour tester.

Indice :
`yaml
- name: Étape principale
run: exit 1 # Simuler un échec

- name: Notification d'erreur
if: failure()
run: echo "ALERTE : le pipeline a échoué !"
`
failure() est vrai si un step précédent du job a retourné un code de sortie non nul.

Vérification : Les logs affichent "ALERTE : le pipeline a échoué !" uniquement quand le step principal échoue.

Tâche 4 : Utiliser always() pour le nettoyage

Ajoutez un step de nettoyage qui s'exécute systématiquement, que le job réussisse ou échoue.

Indice :
`yaml
- name: Nettoyage
if: always()
run: echo "Nettoyage des ressources temporaires"
`
always() est utile pour supprimer des ressources cloud créées en début de job, même en cas d'échec.

Vérification : Le step "Nettoyage" apparaît dans les logs quel que soit le résultat du job.

Tâche 5 : Ignorer le pipeline avec skip-ci

Configurez le workflow pour qu'il ignore les commits dont le message contient [skip ci].

Indice :
`yaml
jobs:
build:
if: "!contains(github.event.head_commit.message, '[skip ci]')"
`
La fonction contains() cherche une sous-chaîne. Le ! inverse la condition. Cette technique est utile pour les commits de documentation ou de mise à jour du README.

Vérification : Un commit avec le message docs: mise à jour README [skip ci] ne déclenche aucun job (tous affichés comme ignorés).

🗂️ Mini-Projet : Workflow avec conditions multiples

yaml

# Checkpoints à valider :
# [ ] Le job deploy porte if: github.ref == 'refs/heads/main'
# [ ] Sur feature/*, deploy est "skipped" dans l'interface
# [ ] Un step with if: failure() s'exécute en cas d'échec
# [ ] Un step with if: always() s'exécute dans tous les cas
# [ ] Un commit avec [skip ci] ne déclenche aucun job
# [ ] Bonus : conditionner sur github.actor pour restreindre le déploiement

Exercice 04 : Contrôler l'exécution avec les conditions if:

🎯 Objectifs

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

✅ Limiter un job à une branche spécifique avec if: github.ref == 'refs/heads/main'
✅ Différencier le comportement selon github.event_name
✅ Exécuter un step de nettoyage uniquement en cas d'échec avec failure()
✅ Ignorer un pipeline via [skip ci] dans le message de commit

Durée estimée : 20 min | Difficulté : ⭐⭐☆☆☆

📖 Contexte

GitHub met à disposition des contextes (github, env, secrets) et des fonctions (success(), failure(), always(), contains()) utilisables dans les conditions.

📋 Énoncé

Vous allez créer un workflow qui démontre quatre types de conditions : limitation par branche, par événement, par statut, et par message de commit.

Résultat attendu :

Le job deploy ne s'exécute que sur la branche main
Un step de notification s'exécute uniquement si le job échoue
Un push avec [skip ci] dans le message ne déclenche rien

🧭 Déroulement

Tâche 1 : Conditionner un job sur la branche

Créez un workflow avec un job deploy qui ne s'exécute que sur la branche main. Testez en poussant sur une branche feature : le job doit être sauté.

Indice :
`yaml
deploy:
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main'
steps:
- run: echo "Déploiement sur production !"
`
Sur une branche feature/x, le job apparaîtra comme "skipped" (gris) dans l'interface.

Vérification : Sur feature/test, le job deploy est affiché comme ignoré (icône grise).

Tâche 2 : Conditionner sur l'événement déclencheur

Ajoutez un step qui affiche un message différent selon que le workflow est déclenché par un push ou une pull_request.

Indice :
`yaml
- name: Message pour push
if: github.event_name == 'push'
run: echo "Déclenché par un push direct"

- name: Message pour PR
if: github.event_name == 'pull_request'
run: echo "Déclenché par une Pull Request"
`

Vérification : En ouvrant une PR, seul le step "Message pour PR" s'exécute.

Tâche 3 : Utiliser failure() pour les notifications

Ajoutez un step de "notification d'erreur" qui ne s'exécute que si un step précédent du même job a échoué. Forcez un échec temporairement pour tester.

Indice :
`yaml
- name: Étape principale
run: exit 1 # Simuler un échec

- name: Notification d'erreur
if: failure()
run: echo "ALERTE : le pipeline a échoué !"
`
failure() est vrai si un step précédent du job a retourné un code de sortie non nul.

Vérification : Les logs affichent "ALERTE : le pipeline a échoué !" uniquement quand le step principal échoue.

Tâche 4 : Utiliser always() pour le nettoyage

Ajoutez un step de nettoyage qui s'exécute systématiquement, que le job réussisse ou échoue.

Indice :
`yaml
- name: Nettoyage
if: always()
run: echo "Nettoyage des ressources temporaires"
`
always() est utile pour supprimer des ressources cloud créées en début de job, même en cas d'échec.

Vérification : Le step "Nettoyage" apparaît dans les logs quel que soit le résultat du job.

Tâche 5 : Ignorer le pipeline avec skip-ci

Configurez le workflow pour qu'il ignore les commits dont le message contient [skip ci].

Indice :
`yaml
jobs:
build:
if: "!contains(github.event.head_commit.message, '[skip ci]')"
`
La fonction contains() cherche une sous-chaîne. Le ! inverse la condition. Cette technique est utile pour les commits de documentation ou de mise à jour du README.

Vérification : Un commit avec le message docs: mise à jour README [skip ci] ne déclenche aucun job (tous affichés comme ignorés).

🗂️ Mini-Projet : Workflow avec conditions multiples

yaml

# Checkpoints à valider :
# [ ] Le job deploy porte if: github.ref == 'refs/heads/main'
# [ ] Sur feature/*, deploy est "skipped" dans l'interface
# [ ] Un step with if: failure() s'exécute en cas d'échec
# [ ] Un step with if: always() s'exécute dans tous les cas
# [ ] Un commit avec [skip ci] ne déclenche aucun job
# [ ] Bonus : conditionner sur github.actor pour restreindre le déploiement