Pruebas de pull requests
Ejecuta un plan de pruebas en cada pull request contra su previsualización y recibe el resultado como un check de GitHub.
Las pruebas de pull requests ejecutan tus recorridos antes de fusionar el código. Cuando se abre o se actualiza una pull request, Autonomy espera a su despliegue de previsualización, ejecuta contra él el plan de pull requests del proyecto e informa del resultado como un check de GitHub.
Úsalas para los recorridos que importan a los revisores pero que no pueden comprobar en los logs de compilación: registro, pago, onboarding, permisos, recibos.
Tres formas de iniciar una ejecución
| Disparador | Qué ocurre |
|---|---|
| Every pull request | Cada commit nuevo en una pull request abierta ejecuta el plan de pull requests del proyecto. Configúralo más abajo. |
Un comentario: @autonomy test the checkout flow against the preview | Un revisor pide una ejecución bajo demanda. Consulta GitHub App. |
| Tu pipeline | Un paso de CI llama a la API de Autonomy cuando conoce la URL de previsualización. Consulta GitHub Actions. |
Configuración
Antes de empezar
- Instala la GitHub App de Autonomy en el repositorio.
- Ten un plan de pruebas cuyas ejecuciones se superen contra un entorno de previsualización o de staging.
- Haz que tu proveedor de hosting notifique a GitHub los despliegues de previsualización, como hacen Vercel y Netlify, o asigna al repositorio un entorno que probar en su lugar.
- En Organization → Integrations → GitHub, conecta GitHub y elige el proyecto del repositorio. Solo administradores.
- Abre Settings → Integrations en el proyecto. En Pull requests, elige el plan de pruebas y activa Run a test plan on every pull request.
- Abre una pull request. El check aparece en cuanto se sube el commit.
Las pull requests en borrador y las que vienen de forks no se ejecutan automáticamente. Cuando se sube un commit más reciente, Autonomy ejecuta el más nuevo.
Cómo funciona una ejecución de pull request
- Se abre, se actualiza, se reabre o se marca como lista para revisión una pull request.
- Autonomy espera hasta 10 minutos al despliegue de previsualización de ese commit. Mientras tanto, el check dice "Waiting for the preview deployment of this commit.".
- El plan se ejecuta contra la previsualización. Si no aparece ninguna, se ejecuta contra el entorno del repositorio y el check lo indica.
- El check se actualiza a medida que terminan las ejecuciones, con un enlace a cada una.
Las ejecuciones automáticas informan solo a través del check. Las ejecuciones que pides en un comentario también mantienen actualizado un comentario en la pull request.
El check
El check se llama Autonomy QA y concluye como:
| Conclusión | Cuándo |
|---|---|
success | Todas las ejecuciones se superaron. |
failure | Una ejecución falló. |
neutral | Una ejecución no pudo empezar, un comentario no se pudo ejecutar o se eliminaron los resultados. |
timed_out | Una ejecución superó su límite de tiempo. |
cancelled | Se cancelaron las ejecuciones. |
Una ejecución fallida hace fallar el check, tanto si no se alcanzó su resultado esperado como si el agente no pudo demostrar que se alcanzó. El check da el motivo de cada ejecución, como "the step ran out of time". Una ejecución con un Runner problem también lo hace fallar, después de que Autonomy ya la haya vuelto a ejecutar una vez; vuelve a ejecutar el check más tarde.
Una ejecución que no pudo empezar deja el check en neutral: no se pudo probar el entorno, así que no hay nada que evaluar.
El check tiene los botones Re-run failed y Re-run all. La opción de volver a ejecutar de GitHub también funciona.
Hacer que el check falle por incidencias
Las incidencias nunca cambian el resultado de una ejecución, así que, por defecto, una ejecución superada supera el check aunque haya notificado una incidencia. Para que los bugs bloqueen la fusión, activa Fail the check on issues en Pull requests, en los ajustes del proyecto. Está desactivado por defecto.
Cuando está activado, un Bug abierto que una ejecución del check encontró o reabrió cambia un check superado a failure: "Failed: a bug was found". Los riesgos, las notas y los bugs que resolviste o ignoraste no cuentan. Consulta Incidencias.
Previsualizaciones protegidas
Si tus previsualizaciones están protegidas, guarda el token de bypass o la contraseña de la previsualización como valor secreto del entorno que usan las ejecuciones. No pongas valores de bypass en los casos de prueba ni en los comentarios de las pull requests.
Solución de problemas
No aparece ningún check
Comprueba que la GitHub App está instalada en el repositorio, que el repositorio tiene un proyecto en Organization → Integrations → GitHub y que el proyecto tiene un plan de pull requests con el interruptor activado. Las pull requests en borrador y las de forks no se ejecutan automáticamente.
Las ejecuciones fueron al entorno del repositorio, no a la previsualización
No se notificó a GitHub ningún despliegue de previsualización de ese commit en 10 minutos. Comprueba que tu proveedor de hosting notifica a GitHub los despliegues de previsualización y que compila uno para cada commit.
El check falló pero todas las ejecuciones se superaron
Fail the check on issues está activado y una ejecución encontró un bug. Abre Issues found en la ejecución.
¿No lo encontraste?