GitHub App

La GitHub App de Autonomy conecta un repositorio con un proyecto. Ejecuta el plan de pull requests del proyecto en cada pull request, convierte un comentario @autonomy en ejecuciones e informa del resultado como un check de GitHub.

Para las ejecuciones iniciadas desde un archivo de workflow, consulta GitHub Actions. Para configurar el plan de pull requests, consulta Pruebas de pull requests.

Configuración

1. Abre Organization → Integrations → GitHub y conecta GitHub. Solo propietarios y administradores.
2. Instala la App para tu organización o cuenta de GitHub y elige los repositorios.
3. Concede los permisos que solicita: Checks (lectura y escritura), Pull requests (lectura y escritura), Contents (lectura), Deployments (lectura).
4. Para cada repositorio, elige su proyecto. Las ejecuciones, los planes de pruebas y los entornos de un repositorio vienen de ese proyecto. Mover un repositorio a otro proyecto borra sus valores predeterminados.
5. Comenta @autonomy help en una pull request para comprobar que la App está escuchando.

Pedir una ejecución en un comentario

Menciona @autonomy, o empieza una línea con /autonomy, y después indica qué 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 lee primero el comentario con una gramática fija. Cuando con ella no puede saber a qué casos de prueba te referías, pide a la IA que elija, pero solo entre los casos de prueba y entornos que existen en el proyecto del repositorio.

Modificadores explícitos

Los verbos test, run, rerun, qa y check se leen con naturalidad y se ignoran, igual que on, in, against y using delante del nombre de un entorno. browser, chrome y desktop significan web; iphone y ipad significan iOS; mobile significa iOS y Android.

preview apunta al último despliegue de previsualización de la pull request. rerun … failed vuelve a ejecutar solo lo que no se superó la última vez.

Cómo se elige el objetivo

1. Una URL explícita en el comentario.
2. Un entorno nombrado en el comentario.
3. El despliegue de previsualización de la pull request, cuando pediste preview.
4. Un entorno cuyo patrón de rama coincide con la rama de la pull request.
5. El valor predeterminado del repositorio.
6. El entorno predeterminado del proyecto.
7. El entorno predeterminado del propio caso de prueba.

Qué recibes

Una ejecución pedida en un comentario mantiene un comentario actualizado en la pull request: el comando que entendió, quién lo pidió y una tabla con el caso de prueba, el objetivo, las plataformas y el resultado, con un enlace a cada ejecución. Las ejecuciones automáticas en cada commit informan solo a través del check.

Cada petición tiene además un check, llamado Autonomy QA, por ejemplo Autonomy QA: 2 passed, 1 failed of 3. Concluye como se describe en Pruebas de pull requests: una ejecución fallida lo deja en failure, y una ejecución que no pudo empezar lo deja en neutral. Un comentario que Autonomy no pudo ejecutar también concluye en neutral, así que una errata nunca bloquea una fusión.

El check tiene los botones Re-run failed y Re-run all.

Límites

• Solo los colaboradores pueden iniciar ejecuciones. Quien comenta debe ser propietario, miembro o colaborador del repositorio. Los bots se ignoran.
• La IA no puede inventar objetivos. Elige entre los casos de prueba y entornos del proyecto, y cualquier URL debe aparecer en tu comentario.
• Producción está protegida. Un entorno que parece de producción solo se usa cuando escribiste su nombre.
• Los objetivos deben ser HTTPS públicos. Se rechazan las direcciones de loopback, las IP privadas, los hosts .local y las URL con credenciales.
• Las peticiones poco claras se rechazan. Si Autonomy no está seguro de lo que querías decir, responde con una sugerencia en lugar de adivinar.
• Como máximo 8 ejecuciones por petición. Un comando que iniciaría más se rechaza, no se recorta.

Iniciar ejecuciones desde CI o tus propias herramientas

Con una clave de API de la organización, llama a run.trigger con exactamente uno de testCaseId o testPlanId, y un environmentSlug guardado o unos targets explícitos. Las mutaciones llevan su clave de idempotencia en el cuerpo JSON.

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

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

Sigue cada ejecución con run.get hasta que su status sea definitivo. Consulta Ejecuciones y evidencia.

Solución de problemas

No pasa nada cuando comento

Comprueba que la App está instalada en el repositorio, que el repositorio tiene un proyecto, que eres propietario, miembro o colaborador, y que la mención es @autonomy o una línea que empieza por /autonomy.

El comentario dice que no encontró un caso de prueba

Nómbralo exactamente con plans:"Exact Name", o configura el plan de pull requests del proyecto para que un comando sin más tenga algo que ejecutar. Solo se busca en el proyecto del repositorio.

La ejecución usó el entorno equivocado

Recorre la lista de «Cómo se elige el objetivo». Un url: o env: explícito siempre tiene prioridad.