Comment créer une CI Node.js avec GitHub Actions ?

npm ci exploite le fichier de verrouillage et échoue si celui-ci n’est pas cohérent avec package.json.

1. Examiner le script de test, le script de lint et le script de build. Corriger les contrôles localement sur une branche de travail.
2. Vérifier la présence de package-lock.json dans le dépôt ; ne pas remplacer npm ci par un npm install silencieux en CI.
3. Identifier la version LTS de Node.js utilisée par le projet et l’exécuteur CI.

node --version
npm --version
npm ci
npm run lint --if-present
npm test
npm run build

Le fichier YAML versionné rend la procédure reproductible et permet de revoir toute modification du pipeline.

1. Ajouter .github/workflows/ci.yml dans une branche dédiée.
2. Déclarer pull_request sur main et push sur main ; limiter les permissions du GITHUB_TOKEN à contents: read.
3. Choisir un runner explicite et des actions référencées par SHA complet, suivant la politique de sécurité.

name: CI Node.js
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  checks:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
        with:
          node-version: '22'
          cache: npm
      - run: npm ci
      - run: npm run lint --if-present
      - run: npm test
      - run: npm run build

La validation doit porter sur le code proposé, avant son intégration à main.

1. Pousser la branche contenant le workflow et ouvrir une pull request ciblant main.
2. Ouvrir les onglets Checks et Actions, puis vérifier l’apparition du job checks dans la bonne exécution.
3. Examiner les journaux d’échec sans y publier de secrets ni de données sensibles.

git status --short
git add .github/workflows/ci.yml
git commit -m "ci: ajouter les controles Node.js"
git push -u origin ma-branche-ci
# Dans GitHub : Pull requests > New pull request

Une CI fiable distingue les erreurs de code, d’environnement et de dépendances.

1. Si npm ci échoue, vérifier la cohérence du lockfile et les éventuels paquets privés nécessitant une politique d’accès.
2. Si un test ou la compilation échoue, corriger le code sur la branche et pousser un nouveau commit.
3. Comparer le contexte d’exécution CI à l’environnement local : version Node.js, variables requises et services externes.

# Diagnostic local (sur une branche de recette)
node --version
npm ci
npm test
npm run build
# Corriger la source puis relancer la PR.

Un workflow informatif ne bloque pas la fusion tant qu’un ruleset ne rend pas le contrôle obligatoire.

1. Attendre qu’au moins une exécution du job checks apparaisse dans le dépôt.
2. Dans Settings > Rules > Rulesets, viser main et exiger la réussite du contrôle publié par le workflow CI Node.js.
3. Tester le blocage sur une pull request de recette et vérifier l’obligation de revue si elle est activée.

# GitHub > Settings > Rules > Rulesets
# Require a pull request before merging
# Require status checks to pass
# Sélectionner le contrôle « checks » du workflow CI Node.js.

Les workflows sont du code opérationnel : leurs dépendances et leurs permissions doivent être maintenues.

1. Attribuer la maintenance des workflows et protéger .github/workflows avec une revue dédiée si la gouvernance l’exige.
2. Conserver les permissions minimales, désactiver les écritures non nécessaires et éviter les secrets dans les workflows de PR.
3. Faire évoluer progressivement les contrôles : tests obligatoires, analyse de dépendances et vérifications de sécurité adaptées au dépôt.

# Checklist avant généralisation
# Permissions GITHUB_TOKEN minimales
# Actions référencées par commit SHA approuvé
# Dépendances installées avec npm ci
# Statuts requis seulement après recette
# Aucun secret exposé aux pull requests non fiables