Anatomie d'un pipeline GitHub Actions

L’intégration continue (CI) consiste à vérifier automatiquement chaque modification poussée sur le dépôt : installation, analyse statique, tests. Le déploiement continu (CD) prolonge la chaîne : une modification validée est livrée automatiquement, en préproduction puis en production. L’ensemble forme un pipeline. L’objectif n’est pas la vitesse pour elle-même, mais la confiance : un problème est détecté quelques minutes après son introduction, par une machine qui ne se lasse jamais de relancer les tests.

Dans ce cours, nous utilisons GitHub Actions, intégré à GitHub. Les notions (déclencheur, job, étape, artefact, environnement, secret) se retrouvent presque à l’identique dans GitLab CI, Azure Pipelines ou Jenkins.

Un premier workflow

Un workflow est un fichier YAML placé dans le dossier .github/workflows/ du dépôt. Le nom du fichier est libre (ci.yml, deploy.yml).

# .github/workflows/ci.yml
name: CI                         # nom affiché dans l'onglet Actions

on:                              # quand le workflow se déclenche
  push:
    branches: [main]
  pull_request:

jobs:
  test:                          # identifiant du job
    runs-on: ubuntu-latest       # machine virtuelle fournie par GitHub
    steps:
      - uses: actions/checkout@v4            # récupère le code du dépôt
      - uses: actions/setup-node@v4          # installe Node.js
        with:
          node-version: 22
      - run: npm ci                          # commande shell
      - run: npm test

Lisons-le de haut en bas :

• on liste les déclencheurs : ici, chaque push sur main et chaque pull request.
• jobs contient un ou plusieurs jobs. Chaque job démarre sur un runner neuf, une machine vierge : rien n’est conservé d’un job à l’autre, sauf ce que vous transmettez explicitement (artefacts, sorties).
• steps est la liste ordonnée des étapes. Une étape fait soit uses: (une action réutilisable, publiée dans un dépôt, avec sa version après @), soit run: (une commande shell, exécutée par bash sur un runner Linux).
• with: passe des paramètres à une action.

Si une étape échoue (code de sortie différent de 0), les étapes suivantes sont sautées et le job est marqué en échec. C’est exactement ce que l’on veut : npm test qui échoue rend le pipeline rouge.

Les déclencheurs

on:
  push:
    branches: [main]
    paths-ignore: ["docs/**", "**.md"]   # ne pas relancer pour la doc
  pull_request:
    branches: [main]                     # PR qui visent main
  workflow_dispatch:                     # bouton « Run workflow »
    inputs:
      environnement:
        type: choice
        options: [staging, production]
  schedule:
    - cron: "0 3 * * 1"                  # chaque lundi à 3 h UTC

• push : à chaque push, filtrable par branches, tags et paths.
• pull_request : à l’ouverture et à chaque nouveau commit d’une pull request. Le code testé est celui de la PR fusionné avec la branche cible.
• workflow_dispatch : lancement manuel depuis l’onglet Actions, avec des paramètres (inputs) lus via ${{ inputs.environnement }}.
• schedule : exécution planifiée, au format cron, en UTC.

Enchaîner des jobs avec needs

Par défaut, les jobs d’un workflow tournent en parallèle. Le mot-clé needs crée une dépendance :

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run lint
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
  build:
    needs: [lint, test]          # attend que lint ET test réussissent
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build

lint et test démarrent ensemble ; build ne démarre que si les deux sont verts. Si l’un échoue, build est marqué « skipped ». L’onglet Actions du dépôt affiche ce graphe, le statut de chaque job et le journal de chaque étape, que l’on déplie pour lire l’erreur.

Rendre la CI obligatoire

Un pipeline rouge n’empêche rien tant qu’on peut fusionner malgré lui. Dans Settings > Branches (règle de protection) ou Settings > Rules > Rulesets, on protège main :

1. exiger une pull request avant de fusionner (plus de push direct) ;
2. exiger que les status checks sélectionnés soient verts, par exemple les jobs lint et test ;
3. éventuellement exiger que la branche soit à jour avec main.

Les noms proposés pour les checks sont ceux des jobs : choisissez des noms stables, car renommer un job requis bloque les pull requests jusqu’à la mise à jour de la règle.

Bonnes habitudes dès le départ

• Gardez le pipeline rapide (quelques minutes) : sinon on cesse d’attendre son verdict.
• Utilisez npm ci (ou pip install -r requirements.txt, composer install) : installation reproductible depuis le fichier de verrouillage.
• Ajoutez timeout-minutes à un job susceptible de rester bloqué.
• Vérifiez la syntaxe localement avec un linter de workflows comme actionlint avant de pousser.