Exercice 01 : Gérer les secrets dans GitHub Actions

🎯 Objectifs

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

✅ Créer un secret dans GitHub → Settings → Secrets and variables → Actions
✅ Référencer ${{ secrets.MON_SECRET }} dans un workflow
✅ Vérifier le masquage automatique *** dans les logs
✅ Créer une variable d'environnement avec vars. et comprendre la différence avec secrets.

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

📖 Contexte

Les workflows GitHub Actions ont souvent besoin de valeurs sensibles : tokens d'API, mots de passe de base de données, clés de déploiement. Ces valeurs ne doivent jamais apparaître en clair dans les fichiers YAML versionnés. GitHub propose deux mécanismes :

Secrets (secrets.) : chiffrés, masqués dans les logs, jamais exposés après création. Idéal pour les tokens, clés SSH, mots de passe.
Variables (vars.) : visibles en clair dans l'interface, non masquées dans les logs. Idéal pour les URLs, noms d'environnements, flags de configuration.

📋 Énoncé

Vous allez créer un secret API_TOKEN et une variable APP_ENV dans les paramètres de votre repository, puis les utiliser dans un workflow pour démontrer leurs comportements différents dans les logs.

Résultat attendu :

La valeur de API_TOKEN apparaît comme *** dans les logs
La valeur de APP_ENV est visible en clair dans les logs

🧭 Déroulement

Tâche 1 : Créer un secret dans GitHub

Rendez-vous dans votre repository → Settings → Secrets and variables → Actions → onglet Secrets. Créez un secret nommé API_TOKEN avec la valeur mon-super-token-secret-123.

Indice : Après avoir cliqué "New repository secret", entrez le nom en majuscules (convention) et la valeur. Une fois créé, la valeur n'est plus jamais visible dans l'interface - vous pouvez seulement la remplacer.

Vérification : Le secret API_TOKEN apparaît dans la liste (sans sa valeur).

Tâche 2 : Créer une variable d'environnement

Dans le même menu → onglet Variables, créez une variable nommée APP_ENV avec la valeur production.

Indice : Les variables sont dans l'onglet "Variables" (pas "Secrets"). Leur valeur est visible dans l'interface et dans les logs des workflows.

Vérification : La variable APP_ENV avec la valeur production apparaît dans la liste.

Tâche 3 : Utiliser le secret dans un workflow

Créez .github/workflows/secrets-demo.yml. Passez API_TOKEN comme variable d'environnement du step et essayez d'afficher sa valeur avec echo.

Indice :
`yaml
- name: Utiliser le secret
env:
TOKEN: ${{ secrets.API_TOKEN }}
run: |
echo "Le token est : $TOKEN"
echo "Longueur : ${#TOKEN}"
`
GitHub remplace automatiquement toute occurrence de la valeur du secret par *** dans les logs.

Vérification : Les logs affichent Le token est : *** et la longueur numérique (non masquée car c'est un nombre calculé).

Tâche 4 : Utiliser une variable vars.

Ajoutez un step qui affiche la variable APP_ENV via ${{ vars.APP_ENV }}.

Indice :
`yaml
- name: Afficher l'environnement
run: echo "Environnement : ${{ vars.APP_ENV }}"
`
Contrairement aux secrets, les variables sont interpolées directement dans le YAML sans masquage.

Vérification : Les logs affichent Environnement : production en clair.

Tâche 5 : Tester avec un secret manquant

Référencez un secret qui n'existe pas (${{ secrets.SECRET_INEXISTANT }}) et observez le comportement.

Indice : Un secret non défini retourne une chaîne vide "". Le workflow ne plante pas. Pour détecter un secret manquant, utilisez : if [ -z "${{ secrets.SECRET_INEXISTANT }}" ]; then echo "Secret non configuré !"; fi

Vérification : Le step s'exécute sans erreur et affiche "Secret non configuré !" si la condition est présente.

🗂️ Mini-Projet : Workflow avec secrets et variables

yaml

# Checkpoints à valider :
# [ ] Le secret API_TOKEN est créé dans Settings → Secrets and variables
# [ ] La variable APP_ENV est créée dans Settings → Variables
# [ ] ${{ secrets.API_TOKEN }} affiche *** dans les logs
# [ ] ${{ vars.APP_ENV }} affiche la valeur en clair
# [ ] Un secret manquant retourne "" sans planter le workflow
# [ ] Bonus : créez un secret d'organisation (si vous avez une org GitHub)

Exercice 01 : Gérer les secrets dans GitHub Actions

🎯 Objectifs

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

✅ Créer un secret dans GitHub → Settings → Secrets and variables → Actions
✅ Référencer ${{ secrets.MON_SECRET }} dans un workflow
✅ Vérifier le masquage automatique *** dans les logs
✅ Créer une variable d'environnement avec vars. et comprendre la différence avec secrets.

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

📖 Contexte

Secrets (secrets.) : chiffrés, masqués dans les logs, jamais exposés après création. Idéal pour les tokens, clés SSH, mots de passe.
Variables (vars.) : visibles en clair dans l'interface, non masquées dans les logs. Idéal pour les URLs, noms d'environnements, flags de configuration.

📋 Énoncé

Résultat attendu :

La valeur de API_TOKEN apparaît comme *** dans les logs
La valeur de APP_ENV est visible en clair dans les logs

🧭 Déroulement

Tâche 1 : Créer un secret dans GitHub

Indice : Après avoir cliqué "New repository secret", entrez le nom en majuscules (convention) et la valeur. Une fois créé, la valeur n'est plus jamais visible dans l'interface - vous pouvez seulement la remplacer.

Vérification : Le secret API_TOKEN apparaît dans la liste (sans sa valeur).

Tâche 2 : Créer une variable d'environnement

Dans le même menu → onglet Variables, créez une variable nommée APP_ENV avec la valeur production.

Indice : Les variables sont dans l'onglet "Variables" (pas "Secrets"). Leur valeur est visible dans l'interface et dans les logs des workflows.

Vérification : La variable APP_ENV avec la valeur production apparaît dans la liste.

Tâche 3 : Utiliser le secret dans un workflow

Créez .github/workflows/secrets-demo.yml. Passez API_TOKEN comme variable d'environnement du step et essayez d'afficher sa valeur avec echo.

Indice :
`yaml
- name: Utiliser le secret
env:
TOKEN: ${{ secrets.API_TOKEN }}
run: |
echo "Le token est : $TOKEN"
echo "Longueur : ${#TOKEN}"
`
GitHub remplace automatiquement toute occurrence de la valeur du secret par *** dans les logs.

Vérification : Les logs affichent Le token est : *** et la longueur numérique (non masquée car c'est un nombre calculé).

Tâche 4 : Utiliser une variable vars.

Ajoutez un step qui affiche la variable APP_ENV via ${{ vars.APP_ENV }}.

Indice :
`yaml
- name: Afficher l'environnement
run: echo "Environnement : ${{ vars.APP_ENV }}"
`
Contrairement aux secrets, les variables sont interpolées directement dans le YAML sans masquage.

Vérification : Les logs affichent Environnement : production en clair.

Tâche 5 : Tester avec un secret manquant

Référencez un secret qui n'existe pas (${{ secrets.SECRET_INEXISTANT }}) et observez le comportement.

Indice : Un secret non défini retourne une chaîne vide "". Le workflow ne plante pas. Pour détecter un secret manquant, utilisez : if [ -z "${{ secrets.SECRET_INEXISTANT }}" ]; then echo "Secret non configuré !"; fi

Vérification : Le step s'exécute sans erreur et affiche "Secret non configuré !" si la condition est présente.

🗂️ Mini-Projet : Workflow avec secrets et variables

yaml

# Checkpoints à valider :
# [ ] Le secret API_TOKEN est créé dans Settings → Secrets and variables
# [ ] La variable APP_ENV est créée dans Settings → Variables
# [ ] ${{ secrets.API_TOKEN }} affiche *** dans les logs
# [ ] ${{ vars.APP_ENV }} affiche la valeur en clair
# [ ] Un secret manquant retourne "" sans planter le workflow
# [ ] Bonus : créez un secret d'organisation (si vous avez une org GitHub)