Configurer les Github Actions

Dans cette leçon, tu vas apprendre à :

1. pousser ton projet React Router 7 sur GitHub ;
2. déclencher un workflow CI dès chaque push ;
3. faire tourner 2 jobs : build (image Docker) et typecheck (TS strict) ;
4. lire les logs pour corriger une erreur de typage avant qu’elle n’atteigne la prod.

En clair : tu poses les bases d’un pipeline de Continuous Integration robuste, première brique indispensable avant le déploiement automatisé.

Préparer le dépôt Git

1
# depuis la racine du projet
2
git init
3
git add .
4
git commit -m "Initial commit"

1. Crée un repo vide sur GitHub.
2. Ajoute-le comme origin, bascule sur main et pousse :

1
git branch -M main
2
git remote add origin git@github.com:<ton-user>/5-configurer-les-github-actions.git
3
git push -u origin main

Première action : builder l’image Docker

Depuis l’onglet Actions de GitHub, sélectionne le template “Docker image” puis clique sur Set up this workflow.

GitHub génère automatiquement un fichier :

1
name: Docker Image CI
2

3
on:
4
  push:
5
    branches: ["main"]
6
  pull_request:
7
    branches: ["main"]
8

9
jobs:
10
  build:
11
    runs-on: ubuntu-latest
12
    steps:
13
      - uses: actions/checkout@v4         # 1️⃣ clone le repo sur le runner
14
      - name: Build the Docker image       # 2️⃣ docker build
15
        run: docker build . -t my-app:latest

actions/checkout@v4 est le “git clone” de la plate-forme – indispensable dans 99 % des workflows.

Valide le fichier avec Commit changes. Un dossier .github/workflows apparaît : ton projet est désormais “CI ready”.

Anatomie d’un workflow GitHub Actions

Ajouter un second job de type-checking

Nous voulons bloquer la CI si le code TypeScript n’est plus valide.

1
 jobs:
2
   build:
3
     …
4
+  typecheck:
5
+    runs-on: ubuntu-latest
6
+    steps:
7
+      - uses: actions/checkout@v4
8
+      - name: Install dependencies
9
+        run: npm ci
10
+      - name: Run typechecking
11
+        run: npm run typecheck

• Pourquoi un second job ?
  • Les jobs tournent en parallèle ➜ pas d’allongement artificiel du temps de CI.
  • Tu sépares clairement “build prod” et “qualité du code”.

📥 Commit, pousse, puis ouvre l’onglet Actions : une nouvelle exécution démarre avec 2 jobs.

Corriger les erreurs de typage

Dans la vidéo, le job typecheck échoue :

1
error TS2322: Type 'undefined' is not assignable to type 'string'.

Reproduis localement :

1
npm run typecheck

La commande plante au même endroit → parfait. Corrige le fichier incriminé (ici users.server.ts), puis relance :

1
npm run typecheck          # ✅ 0 error
2
git add .
3
git commit -m "fix: type error in addUser"
4
git push

Nouvelle exécution GitHub Actions : les deux jobs passent au vert.

Lire les logs pour comprendre un échec

1. Ouvre Actions → build #<id> → typecheck.
2. Chaque step affiche les commandes exécutées et la sortie complète.
3. Clique sur un step pour le replier / déplier.

Le même principe s’applique aux tests unitaires, à des scripts de lint, au build statique, etc.

Bonnes pratiques pour tes futurs workflows

• Un job = un objectif (build, tests, lint, e2e…).
• N’installe les dépendances (npm ci) quand c’est nécessaire.
• Utilise des caches (actions/cache) pour accélérer npm ci sur les jobs lourds.
• Bloque la branche main dans Settings → Branch protection (merge refusé si la CI échoue).
• Garde tes secrets (clé Docker Hub, SSH VPS...) dans Settings → Secrets & variables jamais en clair dans le .yml.

Dans la prochaine leçon on s’attaque au Dockerfile de production : comment embarquer React Router, Prisma et Tailwind dans une image minimaliste, puis pousser cette image sur Docker Hub – prérequis ultime avant le déploiement auto sur ton VPS.