Les Actions du Royaume

GitHub Actions, workflows YAML et automatisation

Qu'est-ce qu'une GitHub Action ?

Une GitHub Action est un workflow automatisé qui s'exécute directement sur les serveurs de GitHub. Tu n'as rien à installer, rien à configurer sur ta machine - GitHub s'occupe de tout.

Le principe est simple : tu décris dans un fichier ce que tu veux qu'il se passe et quand tu veux que ça se passe. GitHub exécute ces instructions automatiquement.

Par exemple :

• À chaque push, lancer les tests
• À chaque pull request, vérifier le style du code
• Chaque nuit à minuit, générer un rapport
• Quand une version est taguée, déployer l'application

Les concepts clés

Avant d'écrire ta première Action, tu dois comprendre le vocabulaire. GitHub Actions utilise cinq concepts fondamentaux :

Workflow - le parchemin d'instructions

Un workflow est un fichier YAML qui décrit un processus automatisé complet. C'est le parchemin que tu écris pour la Forge. Un dépôt peut contenir plusieurs workflows.

Job - la tâche

Un job est un ensemble d'étapes qui s'exécutent sur la même machine. Un workflow peut contenir plusieurs jobs. Par défaut, les jobs s'exécutent en parallèle (en même temps).

Step - l'étape

Un step est une action individuelle à l'intérieur d'un job. Chaque step est soit une commande shell (run:), soit une action réutilisable (uses:).

Action - le composant réutilisable

Une action (avec un "a" minuscule) est un composant préfabriqué que tu peux utiliser dans tes steps. Il en existe des milliers sur le marketplace de GitHub. La plus courante est actions/checkout@v4 qui récupère ton code.

Runner - la machine d'exécution

Un runner est la machine virtuelle sur laquelle ton job s'exécute. GitHub propose des runners gratuits sous Ubuntu, Windows et macOS.

Où placer les workflows ?

GitHub cherche les workflows dans un dossier bien précis :

ton-depot/
  .github/
    workflows/
      mon-workflow.yml
      autre-workflow.yml

Le chemin est toujours .github/workflows/. Si tu places ton fichier ailleurs, GitHub l'ignorera.

Les fichiers doivent avoir l'extension .yml ou .yaml.

Les bases du YAML

Les workflows GitHub Actions sont écrits en YAML (YAML Ain't Markup Language). C'est un format de données lisible par les humains. Voici les règles essentielles :

L'indentation est cruciale

En YAML, l'indentation définit la structure. On utilise des espaces (jamais des tabulations !). Chaque niveau d'imbrication ajoute 2 espaces.

# Correct
parent:
  enfant:
    petit-enfant: valeur

# INCORRECT - mélange d'indentation
parent:
  enfant:
      petit-enfant: valeur   # 6 espaces au lieu de 4 !

Les paires clé-valeur

nom: Tests
version: 1.0
actif: true

Les listes

Les éléments de liste commencent par un tiret suivi d'un espace :

fruits:
  - pomme
  - banane
  - cerise

Les textes sur plusieurs lignes

Le caractère | permet d'écrire du texte sur plusieurs lignes :

script: |
  echo "Première ligne"
  echo "Deuxième ligne"
  echo "Troisième ligne"

Ton premier workflow

Voici le workflow le plus simple possible. Il s'exécute à chaque push et affiche un message :

name: Tests
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Les tests passent !"

Décortiquons chaque ligne :

Les déclencheurs (triggers)

Le mot-clé on: définit quand le workflow se lance. Voici les déclencheurs les plus courants :

À chaque push

on: push

À chaque pull request

on: pull_request

Sur plusieurs événements

on: [push, pull_request]

Sur des branches spécifiques

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

Ce workflow ne se déclenche que pour les pushs sur main ou develop, et pour les pull requests vers main.

Sur un planning (cron)

on:
  schedule:
    - cron: '0 0 * * *'   # Tous les jours à minuit UTC

Manuellement

on: workflow_dispatch

Ce déclencheur ajoute un bouton "Run workflow" dans l'interface GitHub. Très pratique pour les déploiements manuels.

Un workflow plus complet

Voici un workflow réaliste pour un projet avec des tests :

name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Installer les dépendances
        run: npm install

      - name: Lancer les tests
        run: npm test

      - name: Vérifier le style
        run: npm run lint

Jobs multiples et dépendances

Par défaut, les jobs s'exécutent en parallèle. Pour créer des dépendances entre jobs, utilise le mot-clé needs:.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run build

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Déploiement en cours..."

Dans cet exemple :

• test s'exécute en premier
• build attend que test soit terminé avec succès
• deploy attend que build soit terminé avec succès

Si test échoue, ni build ni deploy ne s'exécuteront. C'est exactement le comportement voulu - pas de déploiement si les tests échouent !

Un job peut aussi dépendre de plusieurs jobs :

  deploy:
    needs: [test, build, lint]

Le marketplace - Les outils des autres Maîtres

GitHub dispose d'un marketplace avec des milliers d'actions préfabriquées. Au lieu de tout écrire toi-même, tu peux réutiliser le travail des autres.

Quelques actions populaires :

Exemple avec Node.js :

steps:
  - uses: actions/checkout@v4

  - uses: actions/setup-node@v4
    with:
      node-version: '20'

  - run: npm install
  - run: npm test

Le mot-clé with: permet de passer des paramètres à une action. Ici, on demande Node.js version 20.

Secrets et variables d'environnement

Certaines informations ne doivent jamais apparaître dans ton code : mots de passe, clés API, tokens d'accès. GitHub permet de les stocker en tant que secrets.

Utiliser un secret dans un workflow

steps:
  - name: Déployer
    run: ./deploy.sh
    env:
      API_KEY: ${{ secrets.API_KEY }}
      DB_PASSWORD: ${{ secrets.DB_PASSWORD }}

Les secrets sont configurés dans les Settings du dépôt GitHub, sous "Secrets and variables" > "Actions".

Variables d'environnement simples

Pour les valeurs non sensibles, tu peux définir des variables d'environnement directement :

env:
  NODE_ENV: production
  APP_NAME: mon-application

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Application : $APP_NAME"

Les variables définies au niveau racine sont disponibles dans tous les jobs. Tu peux aussi les définir au niveau d'un job ou d'un step.

Consulter les résultats

Quand un workflow s'exécute, tu peux suivre sa progression dans l'onglet Actions de ton dépôt GitHub.

Les logs

Chaque step produit des logs que tu peux consulter en cliquant dessus. C'est là que tu verras les messages d'erreur si quelque chose échoue.

Les statuts

Chaque exécution a un statut :

• Vert (succès) : tous les jobs ont réussi
• Rouge (échec) : au moins un job a échoué
• Jaune (en cours) : le workflow est en train de s'exécuter
• Gris (annulé) : le workflow a été annulé

Les badges de statut

Tu peux ajouter un badge dans ton README qui affiche le statut du dernier workflow :

![CI](https://github.com/UTILISATEUR/DEPOT/actions/workflows/NOM_DU_FICHIER.yml/badge.svg)

Ce badge se met à jour automatiquement. Vert si les tests passent, rouge sinon. C'est un signal de confiance pour tous ceux qui visitent ton dépôt.

Exercice pratique - Écrire ta première Action

Étape 1 - Créer le dépôt

mkdir forge-actions
cd forge-actions
git init -b main

Étape 2 - Créer la structure des workflows

mkdir -p .github/workflows

C'est le dossier magique que GitHub surveille. Tout fichier .yml placé ici sera traité comme un workflow.

Étape 3 - Créer un script de test

Avant d'écrire le workflow, crée un petit script que le workflow pourra exécuter :

cat > test.sh << 'EOF'
#!/bin/bash
echo "=== Vérification des chroniques ==="
echo "Test 1 : Le fichier README existe..."
if [ -f "README.md" ]; then
    echo "  SUCCÈS"
else
    echo "  ÉCHEC"
    exit 1
fi
echo "Test 2 : Le README n'est pas vide..."
if [ -s "README.md" ]; then
    echo "  SUCCÈS"
else
    echo "  ÉCHEC"
    exit 1
fi
echo "=== Tous les tests passent ==="
EOF

chmod +x test.sh

Étape 4 - Créer le README

cat > README.md << 'EOF'
# Forge Actions

Mon premier dépôt avec GitHub Actions.

![Tests](https://github.com/UTILISATEUR/DEPOT/actions/workflows/verification.yml/badge.svg)
EOF

Étape 5 - Écrire le workflow

C'est le moment crucial. Crée le fichier .github/workflows/verification.yml :

name: Vérification des chroniques
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  verifier:
    runs-on: ubuntu-latest
    steps:
      - name: Récupérer le code
        uses: actions/checkout@v4

      - name: Rendre le script exécutable
        run: chmod +x test.sh

      - name: Lancer les tests
        run: ./test.sh

Vérifie que le fichier est correct :

cat .github/workflows/verification.yml

Étape 6 - Commiter le tout

git add .
git commit -m "Ajouter le workflow de vérification des chroniques"

Étape 7 - Lancer la vérification

bash verifier.sh

.\verifier.ps1

Récapitulatif des concepts