Exercice 01 : Créer un pipeline multi-jobs avec needs

🎯 Objectifs

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

✅ Définir plusieurs jobs dans un même workflow
✅ Lancer des jobs en parallèle (sans needs)
✅ Enchaîner des jobs séquentiellement avec needs: [job-id]
✅ Déclarer un output dans un job et le lire dans un job suivant
✅ Écrire dans le job summary avec $GITHUB_STEP_SUMMARY

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

📖 Contexte

Un workflow avec un seul job est linéaire. Pour des pipelines réels, on veut souvent exécuter plusieurs étapes en parallèle (lint + tests) pour gagner du temps, puis des étapes séquentielles (déploiement après que les tests passent). GitHub Actions gère cela via le mot-clé needs:.

Les outputs de job permettent de passer une valeur (chaîne) d'un job à un autre sans utiliser un artefact.

📋 Énoncé

Vous allez créer un workflow pipeline.yml avec 3 jobs : lint et test en parallèle, puis summary qui dépend des deux et publie un résumé dans le job summary GitHub.

Résultat attendu :

lint et test démarrent simultanément
summary attend que les deux terminent avant de démarrer
Le job summary affiche le statut des deux jobs précédents

🧭 Déroulement

Tâche 1 : Créer le workflow de base

Créez .github/workflows/pipeline.yml avec deux jobs lint et test. Ne mettez aucune dépendance entre eux. Chacun doit se contenter d'afficher un message pour l'instant.

Indice : Deux jobs sans needs: s'exécutent en parallèle. Le runner GitHub les démarre dès que des machines sont disponibles.

Vérification : Dans l'interface Actions, les deux jobs affichent des barres de progression en même temps.

Tâche 2 : Ajouter le job summary avec needs

Ajoutez un troisième job summary qui dépend des deux premiers. Utilisez needs: [lint, test] pour forcer l'exécution séquentielle.

Indice :
`yaml
summary:
runs-on: ubuntu-latest
needs: [lint, test]
`
Le job summary ne démarrera que quand lint ET test seront terminés avec succès.

Vérification : Dans le graphe du workflow, summary est relié par des flèches aux deux premiers jobs.

Tâche 3 : Déclarer un output dans un job

Dans le job test, déclarez un output test_result qui vaut "passed". Pour cela, écrivez dans $GITHUB_OUTPUT avec la syntaxe echo "test_result=passed" >> $GITHUB_OUTPUT.

Indice :
`yaml
test:
runs-on: ubuntu-latest
outputs:
test_result: ${{ steps.run-tests.outputs.test_result }}
steps:
- name: Simuler les tests
id: run-tests
run: echo "test_result=passed" >> $GITHUB_OUTPUT
`
Le id: sur le step est obligatoire pour référencer ses outputs.

Vérification : La section outputs du job test est définie dans le YAML.

Tâche 4 : Lire l'output dans le job suivant

Dans le job summary, lisez l'output du job test via ${{ needs.test.outputs.test_result }} et affichez-le avec echo.

Indice : La syntaxe pour accéder aux outputs d'un job est ${{ needs.<job-id>.outputs.<output-name> }}. Ce contexte n'est disponible que dans un job qui a needs: sur le job source.

Vérification : Les logs du job summary affichent passed.

Tâche 5 : Écrire dans le job summary

Dans le job summary, écrivez un tableau Markdown dans $GITHUB_STEP_SUMMARY pour afficher le statut du pipeline.

Indice :
`yaml
- name: Publier le résumé
run: |
echo "## Résultat du pipeline" >> $GITHUB_STEP_SUMMARY
echo "| Job | Statut |" >> $GITHUB_STEP_SUMMARY
echo "|-----|--------|" >> $GITHUB_STEP_SUMMARY
echo "| Tests | ${{ needs.test.outputs.test_result }} |" >> $GITHUB_STEP_SUMMARY
`

Vérification : L'onglet "Summary" du run GitHub Actions affiche le tableau Markdown rendu.

🗂️ Mini-Projet : Pipeline lint → test → deploy

Étendez le workflow pour simuler un déploiement :

yaml

# Checkpoints à valider :
# [ ] lint et test s'exécutent en parallèle
# [ ] summary démarre uniquement après lint ET test
# [ ] needs: [lint, test] est présent sur le job summary
# [ ] Un output est déclaré dans test et lu dans summary
# [ ] Le job summary GitHub affiche un tableau de résultats
# [ ] Bonus : ajoutez un job deploy qui dépend uniquement de test

Exercice 01 : Créer un pipeline multi-jobs avec needs

🎯 Objectifs

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

✅ Définir plusieurs jobs dans un même workflow
✅ Lancer des jobs en parallèle (sans needs)
✅ Enchaîner des jobs séquentiellement avec needs: [job-id]
✅ Déclarer un output dans un job et le lire dans un job suivant
✅ Écrire dans le job summary avec $GITHUB_STEP_SUMMARY

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

📖 Contexte

Les outputs de job permettent de passer une valeur (chaîne) d'un job à un autre sans utiliser un artefact.

📋 Énoncé

Vous allez créer un workflow pipeline.yml avec 3 jobs : lint et test en parallèle, puis summary qui dépend des deux et publie un résumé dans le job summary GitHub.

Résultat attendu :

lint et test démarrent simultanément
summary attend que les deux terminent avant de démarrer
Le job summary affiche le statut des deux jobs précédents

🧭 Déroulement

Tâche 1 : Créer le workflow de base

Créez .github/workflows/pipeline.yml avec deux jobs lint et test. Ne mettez aucune dépendance entre eux. Chacun doit se contenter d'afficher un message pour l'instant.

Indice : Deux jobs sans needs: s'exécutent en parallèle. Le runner GitHub les démarre dès que des machines sont disponibles.

Vérification : Dans l'interface Actions, les deux jobs affichent des barres de progression en même temps.

Tâche 2 : Ajouter le job summary avec needs

Ajoutez un troisième job summary qui dépend des deux premiers. Utilisez needs: [lint, test] pour forcer l'exécution séquentielle.

Indice :
`yaml
summary:
runs-on: ubuntu-latest
needs: [lint, test]
`
Le job summary ne démarrera que quand lint ET test seront terminés avec succès.

Vérification : Dans le graphe du workflow, summary est relié par des flèches aux deux premiers jobs.

Tâche 3 : Déclarer un output dans un job

Dans le job test, déclarez un output test_result qui vaut "passed". Pour cela, écrivez dans $GITHUB_OUTPUT avec la syntaxe echo "test_result=passed" >> $GITHUB_OUTPUT.

Indice :
`yaml
test:
runs-on: ubuntu-latest
outputs:
test_result: ${{ steps.run-tests.outputs.test_result }}
steps:
- name: Simuler les tests
id: run-tests
run: echo "test_result=passed" >> $GITHUB_OUTPUT
`
Le id: sur le step est obligatoire pour référencer ses outputs.

Vérification : La section outputs du job test est définie dans le YAML.

Tâche 4 : Lire l'output dans le job suivant

Dans le job summary, lisez l'output du job test via ${{ needs.test.outputs.test_result }} et affichez-le avec echo.

Indice : La syntaxe pour accéder aux outputs d'un job est ${{ needs.<job-id>.outputs.<output-name> }}. Ce contexte n'est disponible que dans un job qui a needs: sur le job source.

Vérification : Les logs du job summary affichent passed.

Tâche 5 : Écrire dans le job summary

Dans le job summary, écrivez un tableau Markdown dans $GITHUB_STEP_SUMMARY pour afficher le statut du pipeline.

Indice :
`yaml
- name: Publier le résumé
run: |
echo "## Résultat du pipeline" >> $GITHUB_STEP_SUMMARY
echo "| Job | Statut |" >> $GITHUB_STEP_SUMMARY
echo "|-----|--------|" >> $GITHUB_STEP_SUMMARY
echo "| Tests | ${{ needs.test.outputs.test_result }} |" >> $GITHUB_STEP_SUMMARY
`

Vérification : L'onglet "Summary" du run GitHub Actions affiche le tableau Markdown rendu.

🗂️ Mini-Projet : Pipeline lint → test → deploy

Étendez le workflow pour simuler un déploiement :

yaml

# Checkpoints à valider :
# [ ] lint et test s'exécutent en parallèle
# [ ] summary démarre uniquement après lint ET test
# [ ] needs: [lint, test] est présent sur le job summary
# [ ] Un output est déclaré dans test et lu dans summary
# [ ] Le job summary GitHub affiche un tableau de résultats
# [ ] Bonus : ajoutez un job deploy qui dépend uniquement de test