Exercices corrigés CI/CD : workflows et journaux d'erreurs

name: CI

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  tests:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    services:
      mysql:
        image: mysql:8.4
        env:
          MYSQL_ROOT_PASSWORD: root
          MYSQL_DATABASE: stages_test
        ports:
          - 3306:3306
        options: >-
          --health-cmd="mysqladmin ping -h 127.0.0.1 -proot"
          --health-interval=5s
          --health-timeout=3s
          --health-retries=10
    env:
      DATABASE_URL: mysql://root:root@127.0.0.1:3306/stages_test?serverVersion=8.4
    steps:
      - uses: actions/checkout@v7
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.5'
      - name: Trouver le dossier de cache de Composer
        id: composer-cache
        run: echo "dir=$(composer config cache-files-dir)" >> "$GITHUB_OUTPUT"
      - uses: actions/cache@v6
        with:
          path: ${{ steps.composer-cache.outputs.dir }}
          key: composer-${{ runner.os }}-${{ hashFiles('composer.lock') }}
          restore-keys: |
            composer-${{ runner.os }}-
      - run: composer install --no-interaction --no-progress
      - run: vendor/bin/phpstan analyse
      - run: vendor/bin/phpunit

Points de vigilance : '8.5' entre guillemets (une habitude qui évite le piège de 8.10) ; le contrôle de santé de MySQL avant les tests ; DATABASE_URL au niveau du job, avec un mot de passe qui n'est pas un secret puisque la base est jetable. Selon le projet, une étape php bin/console doctrine:migrations:migrate --no-interaction --env=test crée les tables avant les tests. shivammathur/setup-php est une action tierce très utilisée : dans un vrai projet, épingle-la sur une empreinte de commit.

name: Scripts d'exploitation

on:
  pull_request:
    paths:
      - 'scripts/**'
      - 'compose.yaml'

permissions:
  contents: read

jobs:
  verifier:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - name: ShellCheck
        run: shellcheck scripts/*.sh
      - name: Valider le fichier Compose
        run: docker compose -f compose.yaml config --quiet

ShellCheck renvoie un code d'erreur dès qu'il trouve un problème (variable non protégée par des guillemets, commande mal utilisée) : l'étape devient rouge. docker compose config --quiet lit le fichier, vérifie sa syntaxe et sa structure, et n'affiche rien si tout va bien. Si compose.yaml utilise des variables d'un .env absent du dépôt, il faut fournir des valeurs factices dans le job (env:), sans jamais y mettre de vrais secrets.

name: Audit nocturne

on:
  schedule:
    - cron: '0 1 * * *'
  workflow_dispatch:

permissions:
  contents: read

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      - run: npm audit --audit-level=high
      - name: Signaler l'échec
        if: failure()
        run: echo "Des vulnérabilités hautes ou critiques ont été trouvées" >> "$GITHUB_STEP_SUMMARY"

2 h 00 à Paris en hiver (UTC+1) = 1 h 00 UTC, d'où 0 1 * * *. Sans timezone, cron compte en UTC : en été, l'audit partira à 3 h 00 heure de Paris. Mieux, depuis mars 2026 : - cron: '0 2 * * *' suivi de timezone: Europe/Paris, qui tourne à 2 h 00 à Paris toute l'année. if: failure() ne fait tourner la dernière étape que si une étape précédente a échoué. Quand une exécution planifiée échoue, GitHub prévient la personne qui a modifié en dernier la ligne cron du workflow. Rappel : le workflow doit être sur la branche par défaut pour que schedule et workflow_dispatch fonctionnent.

Quelqu'un a ajouté dayjs dans package.json (à la main, ou avec un npm install dont il n'a pas commité le package-lock.json). Le fichier de verrouillage ne correspond plus : npm ci refuse d'installer, c'est voulu. Correction : lancer npm install en local, vérifier que package-lock.json est modifié, le commiter et pousser. Ne remplace pas npm ci par npm install dans le workflow : tu perdrais la garantie d'installer partout les mêmes versions.

La ligne 14 commence par une tabulation (visible ici par le décalage différent), alors que YAML n'accepte que des espaces pour l'indentation. Remplace-la par des espaces, alignés sur les autres - de la liste. Configure ton éditeur pour insérer des espaces quand tu appuies sur Tab dans les fichiers YAML. Une erreur de syntaxe empêche le workflow de démarrer : aucune étape n'apparaît, seulement ce message.

ECONNREFUSED 127.0.0.1:3306 : rien n'écoute sur le port de MySQL du runner.

• Aucun service MySQL n'est déclaré dans le job : sur le poste de Hugo, MySQL tourne en permanence ; le runner, lui, démarre vide. Correction : ajouter le bloc services: mysql avec ports: - 3306:3306 (tester avec une vraie base).
• Le service existe mais n'est pas prêt, ou son port n'est pas publié : sans contrôle de santé (--health-cmd), les tests démarrent pendant que MySQL s'initialise ; sans ports, il n'est joignable que depuis le réseau des conteneurs. Correction : ajouter les options --health-* et la publication du port.

Une troisième cause possible : l'application lit une variable DB_HOST que le job ne définit pas, et prend une valeur par défaut incorrecte.

Le test importe ../src/Utils/format avec un U majuscule, alors que le dossier s'appelle utils. Windows et macOS ne distinguent pas, par défaut, les majuscules des minuscules dans les noms de fichiers : l'import fonctionne chez Lina. Le runner tourne sous Linux, qui les distingue : le module est introuvable. Correction : écrire ../src/utils/format dans l'import. C'est un bon exemple de ce que la CI apporte : elle révèle les différences d'environnement avant la production, qui tourne elle aussi sous Linux.

Les 23 tests réussissent, mais Jest ne s'arrête pas : une opération asynchrone reste ouverte, très probablement le pool de connexions MySQL, jamais fermé. Le processus attend indéfiniment, jusqu'à ce que timeout-minutes: 15 annule le job. Corrections :

• fermer les ressources à la fin des tests : afterAll(async () => { await pool.end(); }); ;
• trouver la ressource coupable en local avec npx jest --detectOpenHandles ;
• garder un timeout-minutes raisonnable : sans lui, le job aurait tourné jusqu'à la limite par défaut de 6 heures.

L'option --forceExit de Jest ferait disparaître le symptôme sans corriger la fuite : à éviter.

Le jeton GITHUB_TOKEN du job n'a que le droit de lire le contenu (contents: read) : pousser un tag est une écriture, refusée (erreur 403). On donne contents: write au seul job qui pousse le tag :

    permissions:
      contents: write

L'effet de bord : un tag poussé avec GITHUB_TOKEN ne déclenche pas les workflows qui écoutent push: tags (protection contre les boucles). Si un workflow de publication doit partir sur ce tag, on enchaîne la publication dans le même workflow, ou on utilise un jeton d'application GitHub (publier une version).

1. Intégration continue, à chaque pull request et sur main : récupération du code ; installation avec npm ci ; lint et formatage ; tests unitaires ; tests d'intégration contre un service MySQL 8.4 ; revue des dépendances et analyse CodeQL ; construction de l'image Docker et test de fumée de l'image. Livraison, après fusion sur main : publication de l'image sha-… dans ghcr.io ; déploiement automatique en recette avec migration et test de fumée ; déploiement de la même image en production après approbation, puis test de fumée.
2. Un ruleset sur main : pull request obligatoire, une approbation de l'autre développeur, approbation annulée par un nouveau commit, contrôles exigés (lint, tests unitaires, tests d'intégration, construction de l'image), branche à jour, suppressions et push --force interdits, liste de contournement vide. Un fichier CODEOWNERS pour les workflows.
3. Comme secret de l'environnement production, pas du dépôt : seul un job qui déclare environment: production peut la lire, et seulement après l'approbation. Sur le serveur, la clé correspond à un compte deploy sans droits d'administration, limité au script de déploiement. L'empreinte du serveur est enregistrée comme variable (known_hosts).
4. Un environnement GitHub production avec la responsable comme relecteur obligatoire (Required reviewers) ; le job de déploiement en production attend son clic Approve and deploy. Le dépôt étant public, la fonction est disponible avec l'offre gratuite. C'est de la livraison continue : tout est automatique jusqu'à la production, mais une personne décide du moment.
5. Prévenir les utilisateurs et l'équipe ; lancer le retour arrière vers l'image précédente (workflow de retour arrière, avec MIGRER=non) ; vérifier que les réservations refonctionnent ; analyser les journaux de la version fautive ; corriger dans une pull request avec un test qui reproduit le problème ; écrire un post-mortem et ajouter au pipeline le contrôle qui aurait détecté le problème.
6. Par exemple : « J'ai remplacé un déploiement manuel par SFTP par un pipeline GitHub Actions : à chaque pull request, le lint, 64 tests unitaires et d'intégration et une analyse de sécurité tournent automatiquement, et la fusion est bloquée si l'un échoue. Après fusion, la même image Docker est déployée en recette en dix minutes, puis en production après validation de la responsable. Un retour arrière vers la version précédente prend moins de deux minutes. Cela répond aux compétences “Intégrer en continu les versions” et “Mettre à disposition des utilisateurs un service informatique”. »