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 résout 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 la surface conversationnelle. Pour les exécutions déclenchées par pipeline depuis un fichier de workflow, voir GitHub Actions. Les deux coexistent : utilisez Actions pour les exécutions qui doivent se produire à 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, et sélectionnez les dépôts.
3. Accordez les permissions demandées : Checks (lecture et écriture), Pull requests (lecture et écriture), Contents (lecture), Deployments (lecture).
4. Optionnel mais recommandé — sous GitHub Auto-Trigger Defaults, définissez une cible par défaut par dépôt. Un dépôt peut avoir pour 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 é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 le commentaire d'abord avec une grammaire déterministe. Lorsque la grammaire ne peut pas identifier les cas de test visés, il se rabat sur un modèle de langage qui doit choisir parmi les cas de test et environnements existant réellement dans votre espace de travail.

Surcharges explicites

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

Les verbes optionnels en tête — test, run, rerun, qa, check — se lisent naturellement et sont ignorés par le parseur. Idem pour les prépositions on, in, against et using avant un nom d'environnement.

Les mots de plateforme sont aliasés : browser, chrome, firefox, safari et desktop signifient tous web ; iphone et ipad signifient iOS ; mobile signifie iOS et Android.

Deux formulations sont spéciales. 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 ayant échoué la dernière fois.

Comment la cible est choisie

Lorsque plusieurs sources peuvent fournir une cible, Autonomy applique cette priorité :

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 en place au fil de l'exécution — jamais de nouveau fil par mise à jour. Il contient la commande interprétée, l'auteur de la demande, un coût estimé en crédits, et un tableau matriciel cas de test × cible × plateformes × statut, avec un lien profond vers les preuves de chaque exécution. Lorsque le cas de test a une assurance API configurée, le résultat d'assurance est ajouté.

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

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

Les rejets concluent neutral à dessein. Un commentaire malformé ne doit pas bloquer une fusion. Les vrais échecs concluent failure et bloqueront une fusion sous protection de branche.

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

Limites et garde-fous

Le chemin 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 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 environnements candidats qui lui sont fournis, et toute URL qu'il émet doit apparaître littéralement dans votre commentaire.
• La production est protégée. Un environnement dont le nom ressemble à production n'est jamais sélectionné sauf si vous l'avez tapé vous-même.
• Les cibles doivent être en HTTPS public. Les adresses de bouclage, les plages IP privées, les hôtes .local et les URL avec identifiants intégrés sont rejetés.
• Une faible confiance est refusée. Si le modèle n'est pas raisonnablement sûr de ce que vous vouliez dire, Autonomy répond avec une suggestion de syntaxe plutôt que de deviner.
• Le texte du commentaire est considéré comme non 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 ce seuil est rejetée plutôt que tronquée.

L'ouverture d'une pull request ne déclenche pas d'exécution en soi. Une exécution commence lorsqu'un commentaire est posté ou lorsqu'un déclencheur configuré s'active.

Déclenchement depuis la CI ou vos propres outils

Le même pipeline de requêtes agrégées est disponible via l'API REST avec une clé API d'organisation disposant du scope autonomy:runs:write.

1{2  "request": "test the checkout flow against https://preview.example.com"3}

1{2  "requestId": "req_...",3  "status": "queued"4}

Vous pouvez envoyer la même chaîne request en langage naturel, ou un corps structuré avec planIds, environmentSlugs, urls et platforms. Passez un en-tête Idempotency-Key pour qu'une livraison réessayée ne provoque pas de double exécution.

Consultez le résultat :

Dépannage

Rien ne se passe quand 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 une ligne commençant 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:"Nom exact", ou définissez une cible par défaut du dépôt sous GitHub Auto-Trigger Defaults pour qu'une commande simple ait quelque chose à exécuter.

L'exécution a ciblé le mauvais environnement

Parcourez la liste de priorité 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, pas que le produit a échoué — lisez le corps du commentaire pour la raison. Seuls failure et timed_out indiquent un vrai résultat d'exécution.