Exercice 05 : Créer un workflow réutilisable avec workflow_call

🎯 Objectifs

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

• ✅ Créer un workflow avec le trigger on: workflow_call
• ✅ Déclarer des inputs avec différents types (string, boolean, choice)
• ✅ Transmettre des secrets sans les exposer
• ✅ Appeler un workflow réutilisable avec uses: et with: / secrets:

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

📖 Contexte

Quand plusieurs workflows répètent les mêmes étapes (lint, tests, notification), on peut extraire cette logique dans un workflow réutilisable. Il ne se déclenche jamais seul - il attend d'être appelé par un autre workflow avec uses:.

C'est l'équivalent des fonctions en programmation : écrire une fois, appeler partout. La logique de déploiement, de notification, ou de sécurité peut être centralisée dans un seul fichier versionné.

📋 Énoncé

Vous allez créer un workflow réutilisable notify.yml qui simule une notification, puis l'appeler depuis ci.yml en passant des inputs et des secrets.

Résultat attendu :

• notify.yml contient on: workflow_call avec inputs et secrets déclarés
• ci.yml appelle notify.yml avec uses: ./.github/workflows/notify.yml
• Les inputs sont transmis et utilisés dans le workflow appelé

🧭 Déroulement

Tâche 1 : Créer le workflow réutilisable

Créez .github/workflows/notify.yml avec le trigger workflow_call. Ce fichier ne doit pas contenir d'autre trigger (push, pull_request).

Indice :

`yaml

name: Notification Réutilisable

>

on:

workflow_call:

`

Un fichier avec uniquement workflow_call comme trigger ne peut pas être déclenché manuellement depuis l'interface GitHub.

Vérification : Le fichier notify.yml existe et contient on: workflow_call.

Tâche 2 : Déclarer des inputs typés

Ajoutez trois inputs dans notify.yml : status (string, requis), environment (choice entre staging/production, défaut staging), et dry_run (boolean, défaut false).

Indice :

`yaml

on:

workflow_call:

inputs:

status:

required: true

type: string

environment:

required: false

type: choice

options: [staging, production]

default: staging

dry_run:

required: false

type: boolean

default: false

`

Vérification : Les trois inputs sont déclarés avec leur type respectif.

Tâche 3 : Déclarer et utiliser un secret

Ajoutez un secret optionnel WEBHOOK_URL dans notify.yml. Dans le job, affichez un message de notification en utilisant les inputs (ne jamais afficher la valeur du secret dans les logs).

Indice :

`yaml

secrets:

WEBHOOK_URL:

required: false

`

GitHub masque automatiquement les valeurs des secrets dans les logs. Pour vérifier qu'un secret est défini sans l'afficher : if [ -n "${{ secrets.WEBHOOK_URL }}" ].

Vérification : Le workflow utilise ${{ inputs.status }} et ${{ inputs.environment }} dans un echo.

Tâche 4 : Créer le workflow appelant

Créez .github/workflows/ci.yml avec un job build standard, puis ajoutez un job notify qui appelle notify.yml via uses:.

Indice :

`yaml

notify:

needs: build

uses: ./.github/workflows/notify.yml

with:

status: 'success'

environment: production

dry_run: false

secrets:

WEBHOOK_URL: ${{ secrets.WEBHOOK_URL }}

`

Le job qui fait un uses: ne peut pas avoir de steps: ni de runs-on: (c'est le workflow appelé qui définit ses propres runners).

Vérification : ci.yml contient un job avec uses: pointant vers notify.yml.

Tâche 5 : Tester l'appel et observer les logs

Poussez les deux fichiers et observez le graphe du workflow. Le job notify doit appeler le workflow réutilisable et afficher ses logs imbriqués.

Indice : Dans l'interface GitHub Actions, les jobs qui appellent un workflow réutilisable affichent les steps du workflow appelé directement dans leurs logs. Le graphe montre build → notify.

Vérification : Le graphe affiche deux jobs : build et notify. Les logs de notify montrent les steps définis dans notify.yml.

🗂️ Mini-Projet : Workflow réutilisable de déploiement

# Checkpoints à valider :
# [ ] notify.yml contient uniquement on: workflow_call comme trigger
# [ ] Trois inputs sont déclarés (string, choice, boolean)
# [ ] Un secret WEBHOOK_URL est déclaré comme optionnel
# [ ] ci.yml appelle notify.yml via uses: ./.github/workflows/notify.yml
# [ ] Les inputs sont passés via with: dans ci.yml
# [ ] Le graphe du workflow montre les deux jobs et leur dépendance
# [ ] Bonus : créez un troisième workflow qui appelle aussi notify.yml