Tests de pull request
Exécutez un plan de test sur chaque pull request, sur sa prévisualisation, et obtenez le résultat sous forme de check GitHub.
Les tests de pull request exécutent vos parcours avant la fusion du code. Quand une pull request est ouverte ou mise à jour, Autonomy attend son déploiement de prévisualisation, y exécute le plan de pull request du projet et publie le résultat sous forme de check GitHub.
Utilisez-les pour les parcours qui comptent pour les relecteurs mais qu'ils ne peuvent pas vérifier dans les logs de build : inscription, paiement, onboarding, permissions, reçus.
Trois façons de lancer une exécution
| Déclencheur | Ce qui se passe |
|---|---|
| Chaque pull request | Chaque nouveau commit sur une pull request ouverte exécute le plan de pull request du projet. Configurez-le ci-dessous. |
Un commentaire : @autonomy test the checkout flow against the preview | Un relecteur demande une exécution à la volée. Voir Application GitHub. |
| Votre pipeline | Une étape de CI appelle l'API Autonomy dès qu'elle connaît l'URL de prévisualisation. Voir GitHub Actions. |
Configuration
Avant de commencer
- Installez l'application GitHub Autonomy sur le dépôt.
- Disposez d'un plan de test dont les exécutions réussissent sur un environnement de prévisualisation ou de staging.
- Faites en sorte que votre hébergeur signale les déploiements de prévisualisation à GitHub, comme le font Vercel et Netlify, ou donnez au dépôt un environnement à tester à la place.
- Dans Organization → Integrations → GitHub, connectez GitHub et choisissez le projet du dépôt. Réservé aux administrateurs.
- Ouvrez Settings → Integrations dans le projet. Sous Pull requests, choisissez le plan de test et activez Run a test plan on every pull request.
- Ouvrez une pull request. Le check apparaît dès que le commit est poussé.
Les pull requests en brouillon et celles provenant de forks ne sont pas exécutées automatiquement. Quand un commit plus récent est poussé, Autonomy exécute le plus récent.
Déroulement d'une exécution de pull request
- Une pull request est ouverte, mise à jour, rouverte ou marquée comme prête pour la relecture.
- Autonomy attend jusqu'à 10 minutes le déploiement de prévisualisation de ce commit. Pendant ce temps, le check indique « En attente du déploiement de prévisualisation de ce commit. ».
- Le plan s'exécute sur la prévisualisation. Si aucune prévisualisation n'apparaît, il s'exécute à la place sur l'environnement du dépôt, et le check le signale.
- Le check se met à jour à mesure que les exécutions se terminent, avec un lien vers chacune.
Les exécutions automatiques ne rendent compte que via le check. Les exécutions demandées dans un commentaire tiennent aussi à jour un commentaire sur la pull request.
Le check
Le check s'appelle Autonomy QA et se conclut ainsi :
| Conclusion | Quand |
|---|---|
success | Toutes les exécutions ont réussi. |
failure | Une exécution a échoué. |
neutral | Une exécution n'a pas pu démarrer, un commentaire n'a pas pu être exécuté, ou les résultats ont été supprimés. |
timed_out | Une exécution a dépassé son délai maximal. |
cancelled | Les exécutions ont été annulées. |
Une exécution échouée fait échouer le check, que son résultat attendu n'ait pas été atteint ou que l'agent n'ait pas pu montrer qu'il l'a été. Le check donne la raison de chaque exécution, comme « l'étape a manqué de temps ». Une exécution avec un Runner problem le fait aussi échouer, après qu'Autonomy l'a déjà relancée une fois ; relancez le check plus tard.
Une exécution qui n'a pas pu démarrer laisse le check en neutral : l'environnement n'a pas pu être testé, il n'y a donc rien à juger.
Le check comporte les boutons Re-run failed et Re-run all. La relance propre à GitHub fonctionne aussi.
Faire échouer le check en cas de problème
Les problèmes ne modifient jamais le résultat d'une exécution : par défaut, une exécution réussie fait donc passer le check même si elle a signalé un problème. Pour que les bugs bloquent la fusion, activez Fail the check on issues sous Pull requests dans les paramètres du projet. Désactivé par défaut.
Une fois l'option activée, un Bug ouvert qu'une exécution du check a trouvé ou rouvert fait passer un check réussi à failure : « Échec : un bug a été trouvé ». Les risques, les notes et les bugs que vous avez résolus ou ignorés ne comptent pas. Voir Problèmes.
Prévisualisations protégées
Si vos prévisualisations sont protégées, stockez le jeton de contournement ou le mot de passe de prévisualisation comme valeur secrète de l'environnement utilisé par les exécutions. Ne mettez pas de valeurs de contournement dans les cas de test ni dans les commentaires de pull request.
Dépannage
Aucun check n'apparaît
Vérifiez que l'application GitHub est installée sur le dépôt, que le dépôt est associé à un projet dans Organization → Integrations → GitHub, et que le projet a un plan de pull request avec l'option activée. Les pull requests en brouillon et issues de forks ne sont pas exécutées automatiquement.
Les exécutions sont allées sur l'environnement du dépôt, pas sur la prévisualisation
Aucun déploiement de prévisualisation n'a été signalé à GitHub pour ce commit dans les 10 minutes. Vérifiez que votre hébergeur signale les déploiements de prévisualisation à GitHub et qu'il en construit un pour chaque commit.
Le check a échoué alors que toutes les exécutions ont réussi
Fail the check on issues est activé, et une exécution a trouvé un bug. Ouvrez la section Issues found de l'exécution.
Vous n’avez pas trouvé ?