infra / github-actions
Premier workflow complet
Explication
Ce que vous allez apprendre
- Construire un workflow complet, du checkout du code jusqu'au build validé
- Enchaîner logiquement checkout, installation, lint, tests et build dans le bon ordre
- Comprendre pourquoi
npm ciest la commande standard en CI, plutôt quenpm install - Regrouper plusieurs commandes shell dans un seul step avec
run: | - Tester un workflow localement avec
act, avant de le pousser sur GitHub
Dans quel contexte ?
Une développeuse rejoint un projet dont le seul filet de sécurité est la bonne volonté de chacun : "n'oublie pas de lancer les tests avant de pousser". Elle écrit son premier workflow de CI en s'appuyant sur le vocabulaire vu à la leçon précédente (workflow, job, step, action) et automatise ce filet de sécurité : désormais, chaque push et chaque pull request déclenche automatiquement le lint, les tests et le build, sans dépendre de la mémoire de qui que ce soit.
Mettre en pratique le vocabulaire précédent
D'abord, la leçon précédente a posé le vocabulaire : workflow, job, step, action. Cette leçon construit un premier pipeline réel et complet, pour voir comment ces briques s'assemblent concrètement.
Le cas d'usage : vérifier chaque contribution
Le cas d'usage classique est de vérifier automatiquement chaque contribution à un projet, du code source jusqu'au build validé.
Un enchaînement logique d'étapes
Un pipeline de vérification suit presque toujours la même progression : d'abord récupérer le code, le checkout, puis installer l'environnement d'exécution nécessaire, ici Node.js.
| Étape | Rôle |
|---|---|
Checkout (actions/checkout@v4) | Récupère le code source sur la machine du runner |
actions/setup-node@v4 | Installe Node.js à la version demandée |
npm ci | Installe les dépendances de façon strictement reproductible |
| Lint / Tests / Build | Vérifient le code, dans cet ordre, chaque étape dépendant de la précédente |
La suite logique de cet enchaînement
Ensuite installer les dépendances du projet, puis enfin exécuter les vérifications elles-mêmes : linter, tests, build.
Pourquoi cet ordre précis
Chaque étape dépend du succès de la précédente : inutile de lancer des tests sur un code qui ne s'installe même pas correctement. C'est pourquoi un échec arrête, par défaut, tout le reste du job.
Piège fréquent
Utiliser npm install en CI au lieu de npm ci semble équivalent, mais npm install peut modifier silencieusement le package-lock.json et installer des versions légèrement différentes d'une exécution à l'autre — exactement l'inverse de la reproductibilité recherchée en pipeline automatisé.
Une nuance technique : npm ci contre npm install
Une fois cet enchaînement compris, il reste une nuance à connaître. En local, on veut parfois que les dépendances évoluent librement ; en CI, on veut au contraire une installation strictement identique et prévisible à chaque exécution.
Ce que ça illustre plus largement
C'est un exemple concret d'une règle plus générale : ce qui est pratique en développement local n'est pas toujours ce qu'il faut en pipeline automatisé.
Bonne pratique
Avant de pousser un changement de configuration de workflow, teste-le localement avec act push -j test. Ça évite le cycle frustrant "pousser, attendre 3 minutes, découvrir une faute de frappe dans le YAML, recommencer".
Le problème du cycle "pousser, attendre, corriger"
Pousser du code, attendre plusieurs minutes que le pipeline échoue, corriger, recommencer : ce cycle est frustrant et ralentit le travail.
Une solution pour tester avant de pousser
Un outil comme act permet d'exécuter un workflow directement sur ta machine, avant même de pousser quoi que ce soit, pour détecter rapidement les erreurs de configuration évidentes.
La leçon suivante va plus loin sur le déclenchement des workflows : au lieu de réagir à chaque push, choisir précisément quand et pourquoi un pipeline doit se lancer.
Commandes & code
Premier workflow
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout du code
uses: actions/checkout@v4
- name: Installer Node.js
uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm" # met en cache node_modules automatiquement (voir leçon cache)
- name: Installer les dépendances
run: npm ci # "ci" = install strict depuis package-lock.json (pas "install")
- name: Lint
run: npm run lint
- name: Tests
run: npm test -- --coverage
- name: Build
run: npm run build# npm ci vs npm install
# npm ci : installation reproductible, échoue si package-lock.json est désynchronisé, plus rapide
# npm install : peut modifier package-lock.json, à éviter en CI# Ajouter un statut de build visible (badge) dans le README
# # Étape avec plusieurs commandes shell (bloc multi-lignes)
- name: Vérifications combinées
run: |
npm run lint
npm run type-check
npm run test:unit# Exécuter et déboguer un workflow LOCALEMENT avant de pousser (via l'outil "act")
act push -j testRésumé
on.push/on.pull_requestavecbranches:limite les déclenchements aux branches utiles.npm ci(pasnpm install) est la commande standard en CI pour la reproductibilité.run: |permet d'enchaîner plusieurs commandes shell dans un seul step.actpermet de tester des workflows en local, sans consommer de minutes CI GitHub.
Exercices pratiques
Mission : un build vert en local, rouge en CI
Objectif : Diagnostiquer un pipeline qui échoue de façon intermittente à cause de npm install, puis le corriger et le fiabiliser.
Contexte
Le CI d'une équipe échoue environ une fois sur trois avec des erreurs de versions de dépendances différentes de celles installées en local, alors qu'aucune ligne de code n'a changé. En inspectant ci.yml, tu remarques que le step d'installation utilise npm install plutôt que npm ci. Une collègue, lassée d'attendre plusieurs minutes à chaque essai pour découvrir une faute de frappe dans le YAML, aimerait aussi pouvoir tester ses changements avant de les pousser.