Exécutions et preuves

run.trigger met des exécutions en file d'attente et répond immédiatement. Suivez chaque runId renvoyé avec run.get, lisez ce qu'a fait l'agent avec run.step_actions, et obtenez les preuves sur lesquelles repose le résultat de chaque étape avec run.evidence.

Suivre une exécution avec un curseur

Le premier appel à run.get n'a besoin que de l'identifiant de l'exécution. Il répond immédiatement :

1{2  "runId": "jh7examplerunid"3}

Conservez le cursor numérique de la réponse. Pour attendre un changement, envoyez l'identifiant de l'exécution, ce curseur et waitMs :

1{2  "runId": "jh7examplerunid",3  "cursor": 42,4  "waitMs": 250005}

La requête répond dès que l'exécution change (son curseur augmente) ou atteint un statut final. waitMs peut aller de 0 à 25000 millisecondes ; les valeurs supérieures sont ramenées à 25000. Si rien n'a changé pendant ce délai, la réponse contient timedOut: true. Ce n'est pas une erreur : renvoyez le même curseur, ou arrêtez d'attendre.

Les statuts finaux sont passed, failed, couldnt_start et cancelled.

Ce que renvoie run.get

La réponse contient aussi le résumé d'exécution que renvoie run.list : runId, projectId, testCaseId, testCaseName, platforms, environment, trigger (branche, PR, commit), planGroupRunId, startedAt et completedAt.

Statut de l'exécution

status utilise les mêmes résultats d'exécution que le tableau de bord :

Si vous utilisez les exécutions comme garde-fou en CI, ne considérez que passed comme un succès. Les exécutions enregistrées avant ce changement avec un résultat qui n'avait pas pu être prouvé sont renvoyées comme failed, avec leur raison.

État et résultat d'une étape

Chaque étape a un state : not_run (pas encore atteinte, ou l'exécution s'est arrêtée ou n'a pas pu démarrer avant), running, finished ou cancelled. Seule une étape terminée a un result :

Lorsque la cause est connue, failureCategory vaut app_bug, test_flaky, environment, test_error, runner ou unknown. runner signifie que quelque chose a cassé du côté d'Autonomy, par exemple le modèle d'IA était indisponible ou le navigateur du runner s'est arrêté. Autonomy relance automatiquement une telle exécution une fois ; si elle casse de nouveau, elle est failed avec une étiquette Runner problem dans le tableau de bord, et ces tentatives ne sont pas facturées. Une étape qui a manqué de temps relève de environment, pas de runner.

next

next est un conseil, jamais une décision. Décidez à partir de status et de steps.

Lire les Step Actions

run.step_actions liste tout ce que l'agent a fait pour atteindre le résultat attendu de chaque étape, dans l'ordre de début de chaque action :

1{2  "runId": "jh7examplerunid",3  "stepIndex": 0,4  "limit": 1005}

Chaque élément contient actionId, stepIndex (null pour le travail au niveau de l'exécution, comme la préparation et le nettoyage), platform, kind, label, en option summary et detail, outcome (running, ok ou error), startedAt et endedAt. kind vaut l'une de ces valeurs :

• tool : une action sur l'application, la boîte de réception ou le téléphone.
• final_check : le nouveau regard sur le produit, avec lequel le résultat de l'étape doit concorder.
• cleanup : la suppression de ce que l'exécution a créé.
• note : quelque chose que l'agent a consigné en chemin.

Les valeurs que l'exécution a produites ou reçues sont affichées telles quelles ; les valeurs que vous avez enregistrées comme secrets sont masquées et n'apparaissent jamais.

Chaque réponse est un instantané, et son cursor parcourt ce seul instantané. Des actions peuvent arriver en retard avec une heure de début antérieure : le curseur ne peut donc pas suivre une exécution en direct. Chaque réponse contient runCursor, le même compteur que le cursor de run.get. Tant que l'exécution est en cours, et après sa fin tant que le nettoyage est encore rapporté, relisez depuis le début chaque fois que runCursor change. S'il n'a pas changé depuis votre dernière lecture complète, il n'y a rien de nouveau.

Obtenir les preuves

Appelez run.evidence avec runId et, en option, un step numérique :

1{2  "runId": "jh7examplerunid",3  "step": 14}

La réponse a la forme { run: { runId, status }, steps }, avec une entrée pour chaque étape exécutée :

Les preuves n'incluent jamais de noms de modèles d'IA ou de fournisseurs, de prompts, de chiffres de jetons ou de coûts, d'erreurs internes ni de données d'écran brutes.

Liens média signés

Chaque url de média ressemble à ceci :

GET https://api.autonomyqa.com/api/v1/evidence/<id>?kind=<screenshot|frame|video>&exp=<epoch-ms>&sig=<signature>

Un lien fonctionne 15 minutes et ne nécessite aucun identifiant Bearer : la signature porte l'autorisation. Un lien valide redirige (302) vers le fichier. Un lien invalide ou expiré renvoie 403 avec « The evidence link is invalid or has expired. » ; un média manquant renvoie 404. Pour obtenir de nouveaux liens, rappelez run.evidence. Ne modifiez pas la chaîne de requête.

Valeurs d'environnement et secrets

Les environnements contiennent des valeurs nommées que les étapes utilisent sous la forme {{env.NAME}}, dans le texte du résultat attendu ou dans la value, l'address ou le number d'une pièce jointe. Chaque exécution les renseigne à partir de l'environnement dans lequel elle s'exécute. Ici, une étape utilise un code d'invitation enregistré dans l'environnement :

1{2  "id": "join",3  "text": "The grower joins the cooperative with the invite code",4  "attachments": [5    {6      "id": "invite-code",7      "kind": "data",8      "label": "Invite code",9      "value": "{{env.COOP_INVITE_CODE}}",10      "exact": true11    }12  ]13}

Une valeur marquée comme secrète est en écriture seule. environment.list et environment.get ne renvoient que les noms des valeurs (runtimeValueNames), jamais les valeurs. Quand un runner prend en charge l'exécution, Autonomy lui envoie les valeurs secrètes référencées par les étapes. Elles sont renseignées par référence, si bien que l'agent ne les voit jamais, et elles sont masquées dans les Step Actions, les preuves et les journaux. L'API ne renvoie jamais une valeur secrète.

Pour une nouvelle cible API, run.trigger peut transmettre des valeurs dans targets.api.runtimeValues. Voir Environnements pour gérer les valeurs dans le tableau de bord.