Pruebas en pull requests
Ejecuta Autonomy contra despliegues de previsualización y publica un comentario de evidencia y un check run en GitHub.
Las pruebas en pull requests ejecutan Autonomy antes de fusionar el código. Cuando un despliegue de previsualización está listo, Autonomy ejecuta el caso de prueba seleccionado contra esa URL de previsualización y escribe el resultado en GitHub como un único comentario con enlaces de evidencia, además de un check run.
El objetivo no es reemplazar todas las comprobaciones de CI. Usa las ejecuciones de pull request para los recorridos de producto que importan a los revisores pero que no pueden verificar solo con los registros de build: registro, checkout, onboarding, cambios de configuración, permisos, recibos y transferencias de integración.
Dos formas de activar
| Activador | Úsalo cuando |
|---|---|
Un comentario — @autonomy test the checkout flow against the preview | Un revisor quiere una ejecución a demanda, o quiere variar el objetivo o los casos. Consulta la GitHub App. |
| Tu pipeline — un paso del workflow que llama a la API de Autonomy después de conocer la URL de previsualización | La ejecución debe ocurrir en cada push sin que nadie la pida. Consulta GitHub Actions. |
Ambos producen la misma evidencia y reportan a través del mismo comentario y check run.
Requisitos previos
Antes de activar las ejecuciones de PR
- Instala la GitHub App de Autonomy para el repositorio.
- Elige el caso de prueba o plan de pruebas que debe ejecutarse en las pull requests.
- Haz que la URL del despliegue de previsualización esté disponible para Autonomy.
- Ejecuta el caso una vez manualmente antes de tratar el resultado como bloqueante para la fusión.
Configuración
- Conecta el repositorio en Autonomy.
- Instala o confirma la instalación de la GitHub App.
- Conecta el proveedor de despliegue o expón la URL de previsualización desde la CI.
- Configura el objetivo por defecto del repositorio — un caso de prueba o un plan de pruebas — en Settings → Integrations → GitHub Auto-Trigger Defaults, para que un comando sin más tenga algo que ejecutar.
- Abre una pull request, comenta
@autonomy test this PR against the previewy verifica que aparece un único comentario de Autonomy con el estado de la ejecución y el enlace de evidencia.
Cómo funciona
- Se abre o actualiza una pull request.
- Tu proveedor de despliegue crea un entorno de previsualización.
- Autonomy recibe o se le proporciona la URL de previsualización, o la resuelve desde la pull request.
- El caso de prueba o plan seleccionado se ejecuta contra esa URL.
- Autonomy publica un único comentario de GitHub con el estado, la evidencia y los detalles de fallo de mayor señal, además de un check run llamado
Autonomy QA: …. - En pushes posteriores, el comentario existente se actualiza en lugar de crear un hilo nuevo.
Abrir una pull request no inicia una ejecución por sí solo. Una ejecución comienza cuando alguien comenta o cuando tu pipeline llama a la API.
Previsualizaciones protegidas
Si los despliegues de previsualización están protegidos, guarda el token de omisión o la contraseña de previsualización en el almacén de secretos del proveedor. No pongas valores de omisión en casos de prueba, docs MDX ni comentarios de pull request.
Solución de problemas
No aparece ningún comentario
Comprueba que la GitHub App está instalada para el repositorio, que el autor del comentario es un owner, member o collaborator, que la URL de previsualización estaba disponible, que el secreto de la clave de API está presente y que el caso puede ejecutarse manualmente contra la misma URL.
La ejecución apunta a producción
Mueve el paso de Autonomy después del descubrimiento de la URL de previsualización y confirma que la URL pasada a Autonomy es la URL de despliegue de la pull request, no el dominio de producción por defecto. En un comentario, un url: o env: explícito siempre gana sobre cualquier valor por defecto.
La previsualización muestra un muro de autenticación
Añade el token de omisión específico del proveedor o la contraseña de previsualización al entorno que usa la ejecución y reintenta la misma pull request.
El check está en rojo pero el producto funciona bien
Una conclusión neutral significa que el comando fue rechazado — imposible de parsear, ambiguo o no autorizado — no que la ejecución haya fallado. Solo failure y timed_out reflejan un resultado real de ejecución.