GitHub App

La GitHub App de Autonomy convierte un comentario de pull request en una ejecución. Menciona @autonomy con lo que quieres probar y Autonomy determina los casos de prueba, el objetivo y las plataformas, y luego informa en el mismo lugar: un comentario que mantiene actualizado y un check run.

Esta es la interfaz conversacional. Para las ejecuciones activadas por un pipeline desde un archivo de workflow, consulta GitHub Actions. Ambas coexisten: usa Actions para las ejecuciones que deben realizarse con cada push y la App para las que solicita un revisor.

Configuración

1. En el panel, abre Settings → Integrations y conecta GitHub.
2. Autoriza la App para la organización o la cuenta y selecciona los repositorios.
3. Otorga los permisos que solicita: Checks (lectura y escritura), Pull requests (lectura y escritura), Contents (lectura), Deployments (lectura).
4. Opcional pero recomendado: en GitHub Auto-Trigger Defaults, configura un objetivo por defecto para cada repositorio. Un repositorio puede tener por defecto un caso de prueba o un plan de pruebas, pero no ambos.
5. Comenta @autonomy help en cualquier pull request para confirmar que la App está escuchando.

Invocar una ejecución

Menciona @autonomy, o comienza una línea con /autonomy, seguido de lo que quieras ejecutar:

@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 analiza primero el comentario con una gramática determinista. Cuando la gramática no puede identificar a qué casos de prueba te referías, recurre a un modelo de lenguaje que debe elegir entre los casos de prueba y los entornos que realmente existen en tu espacio de trabajo.

Anulaciones explícitas

Todo lo que la gramática reconoce directamente omite el modelo:

Los verbos iniciales opcionales — test, run, rerun, qa, check — se leen de forma natural y el analizador los ignora. Lo mismo ocurre con las preposiciones on, in, against y using antes del nombre de un entorno.

Las palabras de plataforma tienen alias: browser, chrome, firefox, safari y desktop significan web; iphone e ipad significan iOS; mobile significa iOS y Android.

Dos frases son especiales. preview apunta al despliegue de previsualización más reciente del pull request. rerun … failed u only … failed vuelve a ejecutar únicamente los escenarios que fallaron la última vez.

Cómo se elige el objetivo

Cuando varias fuentes podrían proporcionar un objetivo, Autonomy aplica este orden de precedencia:

1. Una URL explícita en el comando.
2. Un entorno con nombre en el comando.
3. El despliegue de previsualización del pull request, cuando se solicitó preview.
4. Un entorno cuyo comparador de ramas coincida con la rama de origen de la PR.
5. El objetivo por defecto del repositorio.
6. El objetivo por defecto del espacio de trabajo.
7. El objetivo por defecto propio del caso de prueba.

Qué recibes

Un comentario de pull request, creado cuando se acepta el comando y actualizado en el mismo lugar a medida que avanza la ejecución, sin crear nunca un hilo nuevo por cada actualización. Contiene el comando que interpretó, quién lo solicitó, un coste estimado en créditos y una tabla matricial de caso de prueba × objetivo × plataformas × estado, con un enlace directo a las evidencias de cada ejecución. Cuando el caso tiene configurado el aseguramiento de API, se añade el resultado del aseguramiento.

Un check run, llamado Autonomy QA: <summary>; por ejemplo, Autonomy QA: 2 passed, 1 failed of 3. Avanza por queued → in_progress → completed y concluye como:

• success — todo pasó.
• failure — al menos una ejecución falló o se produjo un error durante la ejecución.
• timed_out — una ejecución superó su tiempo de espera de ejecución.
• cancelled — las ejecuciones fueron canceladas.
• neutral — el comando fue rechazado: no se pudo analizar, era ambiguo, superaba el límite de fan-out o procedía de un autor de comentarios no autorizado.

Los rechazos concluyen como neutral intencionadamente. Un comentario mal formado no debe bloquear una fusión. Los fallos reales concluyen como failure y bloquearán una fusión cuando haya protección de ramas.

El check run incluye dos botones de acción: Rerun failed scenarios y Rerun all plans. El control nativo de GitHub para volver a ejecutar también funciona.

Límites y protecciones

La vía de lenguaje natural está deliberadamente acotada:

• Solo los colaboradores pueden activar ejecuciones. El autor del comentario debe ser propietario, miembro o colaborador del repositorio. Los comentarios de bots se ignoran por completo.
• El modelo no puede inventar objetivos. Selecciona entre los casos de prueba y entornos candidatos que se le proporcionan, y cualquier URL que genere debe aparecer literalmente en tu comentario.
• Producción está protegida. Un entorno cuyo nombre parezca de producción nunca se selecciona a menos que lo hayas escrito tú mismo.
• Los objetivos deben ser HTTPS públicos. Se rechazan las direcciones de loopback, los rangos de IP privadas, los hosts .local y las URL con credenciales incrustadas.
• Se rechaza la baja confianza. Si el modelo no está razonablemente seguro de lo que quisiste decir, Autonomy responde con una sugerencia de sintaxis en lugar de adivinar.
• El texto del comentario no es de confianza. Se pasa al modelo como datos, nunca como instrucciones.
• El fan-out está limitado a 8 ejecuciones por solicitud. Un comando que se expanda más allá de ese límite se rechaza en lugar de truncarse.

Abrir un pull request no inicia por sí solo una ejecución. Una ejecución comienza cuando alguien comenta o cuando se activa un trigger configurado.

Activar desde CI o tus propias herramientas

La API de operaciones v1 acepta identificadores explícitos de casos de prueba o planes de pruebas con una clave de API de organización que tenga el scope autonomy:runs:write. Las mutaciones incluyen su clave de idempotencia en el cuerpo 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}

Proporciona exactamente uno de testCaseId o testPlanId. Usa environmentSlug para un entorno guardado, o targets para un despliegue o artefacto explícito.

Obtén cada ejecución devuelta enviando su ID mediante POST a run.get:

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

Solución de problemas

No pasa nada cuando comento

Comprueba que la App esté instalada en ese repositorio, que seas propietario, miembro o colaborador y que la mención sea @autonomy o una línea que comience con /autonomy. Comenta @autonomy help para confirmar que la App está recibiendo eventos.

El comentario dice que no pudo identificar un caso de prueba

Especifícalo de forma explícita con plans:"Exact Name", o configura un objetivo por defecto para el repositorio en GitHub Auto-Trigger Defaults para que un comando sin más tenga algo que ejecutar.

La ejecución apuntó al entorno equivocado

Revisa la lista de precedencia anterior. Un url: o env: explícito en el comentario siempre prevalece; si no proporcionaste ninguno, probablemente lo hizo un comparador de ramas o un objetivo por defecto del repositorio.

El check está en rojo, pero nada está roto

Mira la conclusión. neutral significa que el comando fue rechazado, no que el producto fallara; lee el cuerpo del comentario para conocer el motivo. Solo failure y timed_out indican un resultado real de la ejecución.