Maîtriser le YAML de GitHub Actions pour les exécutions de tests CI en tant qu’auteur de pièces de théâtre

Lorsqu’un ensemble de tests Playwright est hébergé sur GitHub, l’étape suivante consiste à faire exécuter automatiquement cet ensemble de tests avec chaque mise à jour (push) et demande de fusion (pull request). GitHub Actions fournit cet environnement d’intégration continue, et le workflow YAML que Playwright peut générer sert de mécanisme pour transformer les événements du répertoire en tests dans le navigateur sur des serveurs cloud. Les équipes qui omettent cette étape découvrent souvent des régressions uniquement sur leur ordinateur portable, des heures après la fusion, ce qui rend plus difficile l’identification de la cause du problème.

Cette présentation couvre :

• la manière dont GitHub Actions s’intègre aux projets Playwright
• ce que détermine le bloc on
• la structure du bloc jobs
• la fonction de chaque étape dans un workflow Playwright typique

Au final, la structure d’un fichier Playwright CI doit être suffisamment lisible pour pouvoir être modifiée lorsque les versions de Node, les navigateurs ou les branches changent. Considérez l’exemple comme un modèle et non comme une boîte noire : une fois que chaque élément est clair, remplacer les exécutants ou ajouter un test de base devient simple.

Introduction aux GitHub Actions et aux fichiers YAML dans Playwright

GitHub Actions est un outil CI/CD hébergé au sein de GitHub. Il permet de compiler, tester et déployer chaque fois que le répertoire est modifié. Pour les frameworks d’automatisation, cela signifie un gain de temps immédiat : les mêmes commandes Playwright s’exécutent sur une image d’exécuteur prédéfinie, sans qu’il soit nécessaire de prendre un ordinateur portable et d’appuyer sur « exécuter ».

Lors d’une installation fraîche via npm init playwright@latest, on est invité à ajouter un workflow GitHub Actions. En acceptant cette proposition, un fichier YAML est créé dans le répertoire .github/workflows. Ce fichier spécifie la version de Node, installe les dépendances et exécute Playwright lors des mises à jour ou des demandes de fusion vers des machines hébergées sur GitHub.

Si cette proposition est refusée, ce même schéma peut être ajouté ultérieurement : il suffit de créer le répertoire .github/workflows et d’y insérer manuellement un fichier YAML de workflow.

La documentation Playwright propose un exemple prêt à l’emploi dans le guide d’introduction aux CI à l’adresse https://playwright.dev/docs/ci-intro. Ce fichier constitue généralement le point de départ pour installer les dépendances, préparer les navigateurs et exécuter des tests à chaque mise à jour ou demande de fusion pertinente.

Comprendre le fichier YAML dans GitHub Actions

L’exemple ci-dessous illustre un flux de travail typique de Playwright. Chaque section détermine quand le processus commence et quelles actions le moteur doit effectuer avant que le statut du PR ne devienne vert ou rouge.

name: Playwright Tests
on:
  push:
    branches: [ main, master ]
  pull_request:
    branches: [ main, master ]
jobs:
  test:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: lts/*
    - name: Install dependencies
      run: npm ci
    - name: Install Playwright Browsers
      run: npx playwright install --with-deps
    - name: Run Playwright tests
      run: npx playwright test
    - uses: actions/upload-artifact@v4
      if: ${{ !cancelled() }}
      with:
        name: playwright-report
        path: playwright-report/
        retention-days: 30

Clé on

La clé on liste les événements qui déclenchent le flux de travail. C’est la porte d’entrée : sans événement correspondant, rien ne s’exécute.

Dans l’exemple, deux familles d’événements sont connectées :

1. Événements de push : un push vers main ou master déclenche le traitement, de sorte que les commits directs sur les branches par défaut sont testés immédiatement.
2. Événements de demande de fusion : l’ouverture ou la mise à jour d’une PR destinée à main ou master déclenche également le traitement, permettant de vérifier les fusions proposées avant qu’elles ne soient appliquées.

Ces déclencheurs couvrent à la fois les commits intégrés et les demandes de révision, ce qui constitue le filet de sécurité sur lequel s’appuient les frameworks d’automatisation.

Aperçu de la section des tâches

Le bloc jobs représente le plan de travail qui s’exécute après qu’un déclencheur ait trouvé une correspondance. Chaque tâche indique généralement :

1. Nom de la tâche : une étiquette comme test qui identifie l’unité de travail.
2. Environnement d’exécution : l’image machine, généralement ubuntu-latest.
3. Délais et conditions : des paramètres tels que timeout-minutes qui déterminent la durée maximale d’exécution de la tâche.
4. Étapes : actions ordonnées — récupération du code, installation, préparation des navigateurs, exécution des tests, téléchargement des artefacts.

Cette section constitue l’ossature du flux de travail : la préparation de l’environnement, l’exécution de Playwright et le stockage des résultats dépendent tous d’elle. Si une tâche échoue, GitHub affiche d’abord le nom de l’étape défaillante, ce qui rend les étiquettes claires très utiles lors de l’analyse des incidents.

Détail des étapes

Récupération du code

Le exécutant doit disposer des fichiers du dépôt. Le checkout est presque toujours effectué en premier ; sans cela, les étapes suivantes n’ont rien à installer ou à exécuter. La plupart des workflows Playwright utilisent l’action officielle de checkout afin que l’arbre de travail corresponde au commit qui a déclenché l’exécution.

Mise en place de Node.js

Playwright repose sur Node. En fixant la version node-version: lts/*, on installe sur l’exécutant la dernière version à support à long terme, ce qui permet aux scripts d’installation et de test d’utiliser un environnement stable. Il est également possible de fixer explicitement une version majeure lorsque le projet utilise déjà localement une ligne LTS standardisée.

Installation des dépendances

npm ci installe les dépendances à partir de package-lock.json dans un arbre propre. Préférez-le à npm install en CI, car l’installation basée sur le lockfile est reproductible entre les exécutions et génère une erreur claire lorsque le lockfile n’est plus à jour par rapport à package.json.

Installer les navigateurs Playwright

Les tests nécessitent des binaires Chromium, Firefox et WebKit ainsi que des paquets système associés. Cette étape télécharge ces navigateurs afin que l’outil de exécution puisse les lancer réellement. L’omission de cette étape est une cause fréquente d’échecs localement réussis mais échoués en CI, lorsque les développeurs ont déjà des navigateurs en cache sur leurs machines.

Exécuter les tests Playwright

C’est là que cela se passe : Playwright exécute les tests du projet sur les navigateurs configurés et indique s’ils réussissent ou échouent. Les échecs se manifestent par une sortie différente de zéro, ce qui empêche la fusion du branch lorsque les règles de protection du branch le requièrent.

Telecharger le rapport de test

Le flux de travail conserve le rapport Playwright généré à l’aide de upload-artifact, souvent avec retention-days: 30, afin que les échecs restent inspectables pendant un mois. Une condition telle que if: ${{ !cancelled() }} permet d’éviter le téléchargement lorsque l’exécution a été annulée plutôt que terminée. Conserver le rapport HTML en tant qu’artefact est généralement plus rapide pour le débogage que de relancer l’ensemble des tests uniquement pour reproduire une assertion instable.