Écrire un workflow de CI

Écrire un workflow de CI

1. Anatomie d'un workflow

   Sur GitHub Actions, un workflow est un fichier YAML dans .github/workflows/. Trois parties : un déclencheur, un ou plusieurs jobs, des étapes.

   name: Intégration continue
   
   on:
     push:
       branches: [main]
     pull_request:
   
   jobs:
     tests:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
   
         - uses: actions/setup-python@v5
           with:
             python-version: '3.12'
             cache: pip
   
         - name: Installer les dépendances
           run: pip install -r requirements.txt
   
         - name: Vérifier la qualité
           run: ruff check .
   
         - name: Exécuter les tests
           run: python -m pytest -q --cov=app --cov-report=term-missing

   Déclencheurs

   on: indique quand la chaîne part. On peut cibler une branche (branches:), un chemin de fichiers (paths:), tags, ou être déclenché par une autre chaîne (workflow_run).

   on:
     push:
       branches: [main]
       paths:
         - 'src/**'
         - 'tests/**'
       paths-ignore:
         - '**.md'      # la doc seule ne déclenche rien

   Ce que l'on ne commit jamais

   • les secrets : ils vont dans les variables d'environnement du dépôt ou du fournisseur ;
   • les fichiers de dépendance générés (node_modules, vendor, .venv) : ils se réinstallent à chaque exécution.

2. Matrice de tests et cache

   Tester sur une seule version masque les problèmes qui n'apparaissent qu'ailleurs. Une matrice se déclare en une ligne.

   jobs:
     tests:
       runs-on: ubuntu-latest
       strategy:
         fail-fast: false        # on veut le résultat de toutes les versions
         matrix:
           python-version: ['3.11', '3.12', '3.13']
           os: [ubuntu-latest, windows-latest]
       steps:
         - uses: actions/checkout@v4
         - uses: actions/setup-python@v5
           with:
             python-version: ${{ matrix.python-version }}
             cache: pip
         - run: pip install -r requirements.txt
         - run: python -m pytest -q

   Chaque combinaison est un job indépendant. Pour suivre la progression d'un job précis, on utilise la syntaxe ${{ matrix.python-version }}.

   Accélérer sans perdre en fiabilité

   • cache des dépendances : le gestionnaire de paquets est configuré pour réutiliser le cache ;
   • paralléliser les étapes indépendantes dans un même job, ou séparer en jobs quand elles sont vraiment indépendantes ;
   • ne pas réinstaller ce qui est déjà là ;
   • filtrer les tests lents dans un job séparé exécuté en parallèle.

3. Cache et gestion du temps d'exécution

   Le cache se déclare sur l'action qui le gère, pas globalement : la clé est calculée à partir d'un fichier qui décrit les dépendances, pour être invalidée dès qu'il change.

   - uses: actions/cache@v4
     with:
       path: ~/.cache/pip
       key: pip-${{ runner.os }}-${{ hashFiles('requirements.txt') }}
       restore-keys: |
         pip-${{ runner.os }}-

   hashFiles porte sur le fichier qui décrit les dépendances : si une dépendance change, la clé change et le cache précédent n'est plus réutilisé.

   Mesurer avant d'optimiser

   1. regarder la durée de chaque étape, pas seulement le total ;
   2. l'étape la plus longue est presque toujours l'installation des dépendances ;
   3. le cache gagne du temps mais occupe de l'espace : et le gain réel se voit dans les statistiques de la plateforme.

4. Exercices

   1. Premier pipeline : écrivez un workflow qui s'exécute à chaque push sur main, installe les dépendances, lance les tests et échoue si la couverture passe sous 80 %.
   2. Cache : ajoutez la mise en cache du gestionnaire de paquets et vérifiez que la seconde exécution est plus rapide.
   3. Matrice : faites tourner les tests sur trois versions du langage et sur deux systèmes, avec fail-fast: false.
   4. Bonus : ajoutez une étape qui ne s'exécute que sur la branche principale.