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 resuelve los casos de prueba, el objetivo y las plataformas, y luego reporta en el mismo lugar — un comentario que se actualiza continuamente y un check run.

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

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 por repositorio. Un repositorio puede tener como objetivo por defecto un caso de prueba o un plan de pruebas, no ambos.
5. Comenta @autonomy help en cualquier pull request para confirmar que la App está escuchando.

Invocar una ejecución

Menciona @autonomy, o inicia una línea con /autonomy, seguido de lo que quieres 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 parsea el comentario primero con una gramática determinista. Cuando la gramática no puede identificar qué casos de prueba quieres, recurre a un modelo de lenguaje que debe elegir entre los casos de prueba y 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 son ignorados por el parser. Lo mismo ocurre con las preposiciones on, in, against y using antes de un nombre de 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 de la pull request. rerun … failed u only … failed vuelve a ejecutar solo los escenarios que fallaron la última vez.

Cómo se elige el objetivo

Cuando varias fuentes podrían suministrar un objetivo, Autonomy aplica esta precedencia:

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

Qué recibes

Un comentario de pull request, creado cuando el comando es aceptado y actualizado conforme la ejecución avanza — nunca un hilo nuevo por actualización. Contiene el comando que entendió, quién lo pidió, un coste estimado de créditos, y una tabla matriz de caso de prueba × objetivo × plataformas × estado, con un enlace directo a la evidencia de cada ejecución. Cuando el caso tiene aseguramiento de API configurado, el resultado del aseguramiento se añade.

Un check run, llamado Autonomy QA: <resumen> — 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 la ejecución dio error.
• timed_out — una ejecución superó su tiempo máximo de ejecución.
• cancelled — las ejecuciones fueron canceladas.
• neutral — el comando fue rechazado: imposible de parsear, ambiguo, por encima del límite de fan-out, o de un autor no autorizado.

Los rechazos concluyen neutral intencionalmente. Un comentario mal formado no debe bloquear una fusión. Los fallos reales concluyen failure y bloquearán una fusión con protección de rama activada.

El check run incluye dos botones de acción: Rerun failed scenarios y Rerun all plans. El control nativo de re-ejecución de GitHub también funciona.

Límites y protecciones

La ruta de lenguaje natural está deliberadamente acotada:

• Solo los colaboradores pueden activar ejecuciones. El autor del comentario debe ser owner, member o collaborator 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 pasan, y cualquier URL que emita debe aparecer literalmente en tu comentario.
• Producción está protegida. Un entorno cuyo nombre parece de producción nunca se selecciona a menos que lo hayas escrito tú mismo.
• Los objetivos deben ser HTTPS público. Direcciones de loopback, rangos de IP privada, hosts .local y URLs con credenciales incrustadas se rechazan.
• Baja confianza se rechaza. 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 es no confiable. Se pasa al modelo como datos, nunca como instrucciones.
• El fan-out tiene un límite de 8 ejecuciones por solicitud. Un comando que se expande más allá se rechaza en lugar de truncarse.

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

Activar desde CI o tu propio tooling

El mismo pipeline de solicitud agregada está disponible a través de la API REST con una clave de API de organización que tenga el 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}

Puedes enviar la misma cadena request en lenguaje natural, o un cuerpo estructurado con planIds, environmentSlugs, urls y platforms. Pasa una cabecera Idempotency-Key para que un reintento de entrega no duplique la ejecución.

Consulta el resultado:

Solución de problemas

No pasa nada al comentar

Comprueba que la App está instalada en ese repositorio, que eres owner, member o collaborator, y que la mención es @autonomy o una línea que empieza con /autonomy. Comenta @autonomy help para confirmar que la App está recibiendo eventos.

El comentario dice que no pudo identificar un caso de prueba

Nómbralo explícitamente con plans:"Nombre exacto", o configura un objetivo por defecto del repositorio en GitHub Auto-Trigger Defaults para que un comando sin más tenga algo que ejecutar.

La ejecución apuntó al entorno incorrecto

Revisa la lista de precedencia de arriba. Un url: o env: explícito en el comentario siempre gana; si no proporcionaste uno, un matcher de rama o un objetivo por defecto del repositorio probablemente lo hicieron.

El check está en rojo pero nada está roto

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