Application GitHub

L'application GitHub Autonomy transforme un commentaire de pull request en exécution. Mentionnez @autonomy avec ce que vous souhaitez tester, et Autonomy détermine les cas de test, la cible et les plateformes, puis rend compte sur place — un commentaire qu'il maintient à jour, et un check run.

C'est l'interface conversationnelle. Pour les exécutions déclenchées par un pipeline depuis un fichier de workflow, consultez GitHub Actions. Les deux coexistent : utilisez Actions pour les exécutions qui doivent avoir lieu à chaque push, et l'application pour celles qu'un relecteur demande.

Configuration

1. Dans le tableau de bord, ouvrez Settings → Integrations et connectez GitHub.
2. Autorisez l'application pour l'organisation ou le compte, puis sélectionnez les dépôts.
3. Accordez les autorisations demandées : Checks (lecture et écriture), Pull requests (lecture et écriture), Contents (lecture), Deployments (lecture).
4. Facultatif mais recommandé — sous GitHub Auto-Trigger Defaults, définissez une cible par défaut pour chaque dépôt. Un dépôt peut avoir par défaut un cas de test ou un plan de test, mais pas les deux.
5. Commentez @autonomy help sur n'importe quelle pull request pour confirmer que l'application est à l'écoute.

Lancer une exécution

Mentionnez @autonomy, ou commencez une ligne par /autonomy, suivi de ce qu'il faut 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 analyse d'abord le commentaire avec une grammaire déterministe. Lorsque la grammaire ne peut pas déterminer quels cas de test vous visiez, il se rabat sur un modèle de langage qui doit choisir parmi les cas de test et les environnements qui existent réellement dans votre espace de travail.

Surcharges explicites

Tout ce que la grammaire reconnaît directement contourne le modèle :

Les verbes facultatifs placés en tête — test, run, rerun, qa, check — se lisent naturellement et sont ignorés par l'analyseur. Il en va de même pour les prépositions on, in, against et using avant un nom d'environnement.

Les termes désignant les plateformes ont des alias : browser, chrome, firefox, safari et desktop signifient tous web ; iphone et ipad signifient iOS ; mobile signifie iOS et Android.

Deux formulations sont particulières. preview cible le dernier déploiement de prévisualisation de la pull request. rerun … failed ou only … failed ne réexécute que les scénarios qui ont échoué la dernière fois.

Comment la cible est choisie

Lorsque plusieurs sources peuvent fournir une cible, Autonomy applique l'ordre de priorité suivant :

1. Une URL explicite dans la commande.
2. Un environnement nommé dans la commande.
3. Le déploiement de prévisualisation de la pull request, lorsque preview a été demandé.
4. Un environnement dont le filtre de branche correspond à la branche source de la PR.
5. La cible par défaut du dépôt.
6. La cible par défaut de l'espace de travail.
7. La cible par défaut propre au cas de test.

Ce que vous recevez

Un commentaire de pull request, créé lorsque la commande est acceptée et mis à jour sur place au fil de l'exécution — jamais un nouveau fil à chaque mise à jour. Il contient la commande comprise, l'auteur de la demande, une estimation du coût en crédits et un tableau matriciel cas de test × cible × plateformes × statut, avec un lien direct vers les preuves de chaque exécution. Lorsque le cas dispose d'une assurance API configurée, le résultat de l'assurance est ajouté.

Un check run, nommé Autonomy QA: <summary> — par exemple Autonomy QA: 2 passed, 1 failed of 3. Il passe par queued → in_progress → completed et se conclut par :

• success — tout a réussi.
• failure — au moins une exécution a échoué, ou une erreur d'exécution s'est produite.
• timed_out — une exécution a dépassé son délai maximal.
• cancelled — les exécutions ont été annulées.
• neutral — la commande a été rejetée : impossible à analyser, ambiguë, dépassant la limite de fan-out ou provenant d'un auteur de commentaire non autorisé.

Les rejets se concluent volontairement par neutral. Un commentaire mal formé ne doit pas bloquer une fusion. Les véritables échecs se concluent par failure et bloqueront une fusion lorsque la protection de branche est activée.

Le check run comporte deux boutons d'action : Rerun failed scenarios et Rerun all plans. Le contrôle de réexécution natif de GitHub fonctionne également.

Limites et garde-fous

Le parcours en langage naturel est délibérément encadré :

• Seuls les collaborateurs peuvent déclencher des exécutions. L'auteur du commentaire doit être propriétaire, membre ou collaborateur du dépôt. Les commentaires provenant de bots sont entièrement ignorés.
• Le modèle ne peut pas inventer de cibles. Il sélectionne parmi les cas de test et les environnements candidats qui lui sont transmis, et toute URL qu'il produit doit apparaître littéralement dans votre commentaire.
• La production est protégée. Un environnement dont le nom évoque la production n'est jamais sélectionné, sauf si vous l'avez saisi vous-même.
• Les cibles doivent être accessibles publiquement en HTTPS. Les adresses de bouclage, les plages d'adresses IP privées, les hôtes .local et les URL contenant des identifiants intégrés sont rejetés.
• Une faible confiance entraîne un refus. Si le modèle n'est pas raisonnablement certain de ce que vous vouliez dire, Autonomy répond avec une suggestion de syntaxe plutôt que de deviner.
• Le texte du commentaire n'est pas fiable. Il est transmis au modèle en tant que données, jamais en tant qu'instructions.
• Le fan-out est plafonné à 8 exécutions par requête. Une commande qui dépasse cette limite est rejetée plutôt que tronquée.

L'ouverture d'une pull request ne déclenche pas à elle seule une exécution. Une exécution commence lorsque quelqu'un publie un commentaire, ou lorsqu'un déclencheur configuré s'active.

Déclenchement depuis la CI ou vos propres outils

L'API d'opérations v1 accepte des identifiants explicites de cas de test ou de plan de test avec une clé API d'organisation disposant du scope autonomy:runs:write. Les mutations incluent leur clé d'idempotence dans le corps JSON.

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

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

Transmettez exactement l'un des deux identifiants testCaseId ou testPlanId. Utilisez environmentSlug pour un environnement enregistré, ou targets pour un déploiement ou un artefact explicite.

Récupérez chaque exécution renvoyée en envoyant son identifiant à run.get via une requête POST :

1{2  "runId": "run_..."3}

Dépannage

Rien ne se passe lorsque je commente

Vérifiez que l'application est installée sur ce dépôt, que vous êtes propriétaire, membre ou collaborateur, et que la mention est @autonomy ou qu'une ligne commence par /autonomy. Commentez @autonomy help pour confirmer que l'application reçoit les événements.

Le commentaire indique qu'il n'a pas pu identifier un cas de test

Nommez-le explicitement avec plans:"Exact Name", ou définissez une cible par défaut pour le dépôt sous GitHub Auto-Trigger Defaults afin qu'une commande simple ait quelque chose à exécuter.

L'exécution a ciblé le mauvais environnement

Parcourez la liste de priorités ci-dessus. Un url: ou env: explicite dans le commentaire l'emporte toujours ; si vous n'en avez pas fourni, un filtre de branche ou une cible par défaut du dépôt en est probablement la cause.

Le check est rouge, mais rien n'est cassé

Regardez la conclusion. neutral signifie que la commande a été rejetée, et non que le produit a échoué — lisez le corps du commentaire pour en connaître la raison. Seuls failure et timed_out indiquent le résultat réel d'une exécution.