À propos de cet outil
La plupart des suites de tests ont besoin du même squelette de CI : récupérer le code, installer un runtime, installer les dépendances et les navigateurs, lancer les tests et conserver le rapport en cas d’échec. Ce générateur écrit ce workflow pour Playwright (TypeScript), Cypress, Selenium avec Java et Maven, ou pytest, en utilisant les versions majeures actuelles des actions officielles (checkout@v4, setup-node@v4, setup-java@v4, setup-python@v5, cache@v4, upload-artifact@v4). Pour Playwright, il peut répartir la suite sur des jobs parallèles avec --shard=i/n, puis fusionner les rapports blob en un seul rapport HTML, selon le schéma documenté par Playwright. Les exécutions planifiées utilisent le cron à 5 champs en UTC, comme l’exige GitHub Actions.
Mode d’emploi
- Choisissez votre framework et la version du runtime, puis les déclencheurs : push, pull_request, un planning cron ou un workflow_dispatch manuel.
- Sélectionnez les navigateurs et, pour Playwright, un nombre de shards. Gardez le cache et l’envoi du rapport activés sauf raison contraire.
- Copiez ou téléchargez le YAML, enregistrez-le dans .github/workflows/ de votre dépôt, et vérifiez que des commandes comme npm ci ou pip install -r requirements.txt correspondent à votre projet.
FAQ : Générateur de workflow GitHub Actions pour tests
Pourquoi le planning s’exécute-t-il à une autre heure que prévu ?
GitHub Actions évalue le cron en UTC : convertissez depuis votre fuseau horaire local. Les exécutions planifiées peuvent aussi démarrer en retard aux périodes chargées, et dans les dépôts publics les workflows planifiés sont automatiquement désactivés après 60 jours sans activité sur le dépôt.
Comment fonctionne le sharding Playwright ici ?
Une matrice lance un job par shard, et chacun exécute npx playwright test --shard=i/n avec le reporter blob. Un job suivant télécharge tous les rapports blob et exécute npx playwright merge-reports pour produire un seul artefact de rapport HTML.
Où mettre des identifiants comme le mot de passe d’un utilisateur de test ?
Stockez-les comme secrets de dépôt ou d’environnement et référencez-les avec ${{ secrets.NAME }} dans un bloc env. Ne les committez jamais dans le fichier de workflow.