Pignons en acier

Configurer des étapes d'intégration continue avec GitHub

Nous appelons ces étapes « GitHub Actions » ; elles permettent d'améliorer et d'automatiser vos workflows.

Au début de l’année dernière, j’ai travaillé sur un modèle de projet basé Vue et Supabase, et j’ai pensé qu’il serait judicieux d’automatiser certaines étapes, comme le recommande la communauté en matière de bonnes pratiques.

Je vais en décrire deux afin de montrer comment utiliser les actions GitHub pour effectuer ces étapes automatiquement lorsqu’un événement déclencheur se produit sur mon référentiel de code.

L’action « Vérifier que le code compile »

Souvent, nous mettons en œuvre une bonne pratique consistant à automatiser la vérification que le code poussé vers un référentiel de code fonctionne pour tout le monde.

Ainsi, lorsqu’un programmeur soumet une requête de tirage pour fusionner ses modifications de code dans la branche develop et pour garantir que sa branche se compile avec succès, nous déclenchons automatiquement une compilation et la commande de compilation appropriée pour le projet est exécutée.

Dans mon projet, je dois exécuter npm run build.

Le déclencheur

Dans GitHub Actions, vous définissez le déclencheur comme suit.

1
2
3
4
5
on:
  pull_request:
    branches:
      - develop
    types: [opened, synchronize, reopened]

Il cible la branche develop dans le contexte d’une requête de tirage. Il ne se déclenche que sur les requêtes de tirage ouvertes ou réouvertes.

Il se déclenche également lorsque du nouveau code est poussé vers la branche feature uniquement lorsqu’une requête de tirage existe entre cette branche et develop. Ce dernier cas d’utilisation se produit souvent lorsque les développeurs examinent mutuellement leur code et suggèrent des ajustements dans le code.

Les étapes

Ensuite, nous définissons les étapes à exécuter :

  1. L’étape Checkout code extrait le code du référentiel dans le processus d’exécution.
  2. L’étape Configurer Node.js installe la dernière version LTS de Node.js et active la mise en cache npm pour des installations plus rapides.
  3. L’étape Installer les dépendances installe tous les paquets npm requis à l’aide de npm ci pour une configuration propre et reproductible.
  4. L’étape Exécuter la compilation exécute le processus de compilation du projet à l’aide de npm run build.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "lts/*"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Run build
        run: npm run build

Comment tester

Créez un fichier YAML pr-build.yml contenant les extraits décrits ci-dessus dans un dossier .github/workflows à la racine de votre projet.

Ensuite, poussez la branche de fonctionnalité et créez une requête de tirage. Cela devrait déclencher l’action GitHub.

L’action « Créer une version sémantique »

Ce processus nécessite une configuration plus complexe, mais je vais vous guider pas à pas, comme d’habitude.

Abonnez-vous !

J’ai prévu un article sur le sujet des versions sémantiques en février 2026. Il complétera bien cette action GitHub.

Pour l’instant, permettez-moi de commenter les parties importantes du code YAML ci-dessous :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
# release.yml
name: Automatic Release
run-name: ${{ github.actor }} is automatically releasing 🚀

on:
  # L'action GitHub s'exécutera automatiquement lors des commits
  # vers la branche principale, par exemple lorsque vous fusionnez
  # une requête de tirage de la branche develop vers la branche
  # principale.
  # Cela suppose que les branches develop et main sont protégées,
  # ce qui signifie que vous ne pouvez pas pousser directement vers
  # ces branches sans passer par une pull request.  push:
  branches:
    - main

jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    environment:
      # Il s'agit du nom de votre environnement créé
      # sous https://github.com/{user}/{repo_name}/settings/environments/.
      # Le nom doit correspondre au code YAML et aux paramètres.
      name: CI
    steps:
      # À l'aide des variables secrètes d'environnement définies
      # sous https://github.com/{user}/{repo_name}/settings/environments/,
      # nous générerons un jeton utilisé pour permettre à l'étape
      # de publication sémantique de modifier le fichier
      # CHANGELOG.md lors de la création de la publication
      # (voir l'étape « Publication sémantique » ci-dessous).      - name: "Generate token"
        id: generate_token
        uses: tibdex/github-app-token@v1
        with:
          app_id: ${{ secrets.GH_APP_ID }}
          private_key: ${{ secrets.GH_APP_KEY }}
      # Consultez le code pour pouvoir exécuter la création de
      # la version, car cela nécessite certains paquets npm.
      - name: Checkout
        uses: actions/checkout@v4
        with:
          persist-credentials: false
          fetch-depth: 0
          ref: ${{ github.event.pull_request.base.ref }}
      # Installer Node LTS
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "lts/*"
          cache: "npm"
      # S'assurer que toutes les dépendances sont correctes et
      # installées, en particulier les paquets de publication
      #sémantique.
      - name: "Installing dependencies"
        run: npm ci
      - name: "Verifying the signatures"
        run: npm audit signatures
      # Exécuter la création de version semantique
      - name: Semantic Release
        uses: cycjimmy/semantic-release-action@v4
        # Nous utilisons ici le jeton généré lors de la première étape.
        env:
          GITHUB_TOKEN: ${{ steps.generate_token.outputs.token }}

Abonnez-vous pour connaître tous les détails nécessaires à la mise en place sur le projet le versionning sémantique et à sa configuration selon vos besoins. L’article est prévu pour le 9 février 2026.

Conclusion

Vous pouvez aller beaucoup plus loin avec les GitHub Actions, mais c’est déjà un bon début !

Et vous, à quoi vous sert GitHub Actions dans vos tâches quotidiennes ?

Suivez-moi !

Merci d’avoir lu cet article. Assurez-vous de me suivre sur X, de vous abonner à ma publication Substack et d’ajouter mon blog à vos favoris pour ne pas manquer les prochains articles.

Photo de Pixabay.