Application GitHub

L'application GitHub Autonomy relie un dépôt à un projet. Elle exécute le plan de pull request du projet sur chaque pull request, transforme un commentaire @autonomy en exécutions et rend compte sous forme de check GitHub.

Pour les exécutions lancées depuis un fichier de workflow, voir GitHub Actions. Pour configurer le plan de pull request, voir Tests de pull request.

Configuration

1. Ouvrez Organization → Integrations → GitHub et connectez GitHub. Réservé aux propriétaires et aux administrateurs.
2. Installez l'application pour votre organisation ou votre compte GitHub, et choisissez les dépôts.
3. Accordez les permissions demandées : Checks (lecture et écriture), Pull requests (lecture et écriture), Contents (lecture), Deployments (lecture).
4. Pour chaque dépôt, choisissez son projet. Les exécutions, plans de test et environnements d'un dépôt proviennent de ce projet. Déplacer un dépôt vers un autre projet efface ses valeurs par défaut.
5. Commentez @autonomy help sur une pull request pour vérifier que l'application est à l'écoute.

Demander une exécution dans un commentaire

Mentionnez @autonomy, ou commencez une ligne par /autonomy, puis indiquez quoi exécuter :

@autonomy test the checkout flow against the Vercel preview
@autonomy run plans "Signup", "Checkout" on staging and preview
@autonomy test this PR using https://deploy-preview-128.example.com
@autonomy rerun only the failed scenarios
@autonomy help

Autonomy lit d'abord le commentaire selon une grammaire fixe. Quand celle-ci ne permet pas de savoir quels cas de test vous visiez, il demande à l'IA de choisir, mais uniquement parmi les cas de test et les environnements qui existent dans le projet du dépôt.

Paramètres explicites

Les verbes test, run, rerun, qa et check rendent la phrase naturelle et sont ignorés, tout comme on, in, against et using devant un nom d'environnement. browser, chrome et desktop désignent le web ; iphone et ipad désignent iOS ; mobile désigne iOS et Android.

preview cible le dernier déploiement de prévisualisation de la pull request. rerun … failed ne relance que ce qui n'a pas réussi la dernière fois.

Choix de la cible

1. Une URL explicite dans le commentaire.
2. Un environnement nommé dans le commentaire.
3. Le déploiement de prévisualisation de la pull request, si vous avez demandé preview.
4. Un environnement dont le filtre de branche correspond à la branche de la pull request.
5. La valeur par défaut du dépôt.
6. L'environnement par défaut du projet.
7. L'environnement par défaut du cas de test lui-même.

Ce que vous obtenez en retour

Une exécution demandée par commentaire tient à jour un seul commentaire sur la pull request : la commande comprise, qui l'a demandée, et un tableau avec le cas de test, la cible, les plateformes et le résultat, ainsi qu'un lien vers chaque exécution. Les exécutions automatiques sur chaque commit ne rendent compte que via le check.

Chaque demande a aussi un seul check, nommé Autonomy QA, par exemple Autonomy QA: 2 passed, 1 failed of 3. Il se conclut comme décrit dans Tests de pull request : une exécution échouée le passe en failure, une exécution qui n'a pas pu démarrer le passe en neutral. Un commentaire qu'Autonomy n'a pas pu exécuter se conclut aussi en neutral, si bien qu'une faute de frappe ne bloque jamais une fusion.

Le check comporte les boutons Re-run failed et Re-run all.

Limites

• Seuls les collaborateurs peuvent lancer des exécutions. L'auteur du commentaire doit être propriétaire, membre ou collaborateur du dépôt. Les bots sont ignorés.
• L'IA ne peut pas inventer de cibles. Elle choisit parmi les cas de test et les environnements du projet, et toute URL doit figurer dans votre commentaire.
• La production est protégée. Un environnement qui ressemble à la production n'est utilisé que si vous avez tapé son nom.
• Les cibles doivent être en HTTPS public. Les adresses de bouclage, les IP privées, les hôtes .local et les URL contenant des identifiants sont refusés.
• Les demandes ambiguës sont refusées. Si Autonomy n'est pas sûr de ce que vous vouliez, il répond par une suggestion au lieu de deviner.
• 8 exécutions au maximum par demande. Une commande qui en lancerait davantage est refusée, pas tronquée.

Lancer des exécutions depuis la CI ou vos propres outils

Avec une clé d'API d'organisation, appelez run.trigger avec exactement l'un des champs testCaseId ou testPlanId, et soit un environmentSlug enregistré, soit des targets explicites. Les mutations transmettent leur clé d'idempotence dans le corps JSON.

1{2  "testPlanId": "...",3  "environmentSlug": "preview",4  "branch": "feature/checkout",5  "pr": "123",6  "idempotencyKey": "github:123456789:1"7}

1{2  "runIds": [3    "..."4  ],5  "planGroupRunId": "...",6  "environment": {7    "slug": "preview",8    "name": "Preview"9  }10}

Suivez chaque exécution avec run.get jusqu'à ce que son status soit définitif. Voir Exécutions et preuves externes.

Dépannage

Rien ne se passe quand je commente

Vérifiez que l'application est installée sur le dépôt, que le dépôt est associé à un projet, que vous êtes propriétaire, membre ou collaborateur, et que la mention est @autonomy ou une ligne commençant par /autonomy.

Le commentaire indique qu'aucun cas de test n'a été trouvé

Nommez-le exactement avec plans:"Exact Name", ou définissez le plan de pull request du projet pour qu'une commande sans précision ait quelque chose à exécuter. Seul le projet du dépôt est consulté.

L'exécution a utilisé le mauvais environnement

Reprenez la liste de la section « Choix de la cible ». Un url: ou un env: explicite l'emporte toujours.