Cómo leer una regresión y sus commits candidatos

Cuándo Qably marca una regresión, qué es el rango de commits candidatos, qué necesita para mostrarlo y qué hacer cuando no puede.

Una regresión es un caso que dejó de pasar. Qably la marca y, cuando puede, lista los commits que llegaron entre las dos ejecuciones. Lea esa lista como un conjunto de pistas, no como una respuesta.

Qué cuenta como regresión

Qably compara cada ejecución terminada con la ejecución terminada anterior de la misma suite. Un caso es una regresión cuando pasó en esa ejecución y falla en esta. El cambio contrario, de falla a éxito, es un arreglo. Un caso que antes estaba omitido o bloqueado, o que es nuevo en esta ejecución, no es ninguna de las dos cosas.

Se ve en tres lugares:

Lista de ejecuciones: cada ejecución muestra tres conteos frente a la anterior: regresiones, arreglos y casos sin cambio.
Detalle de la ejecución: el bloque Qué cambió lista los casos bajo "Empezaron a fallar" y "Se arreglaron".
Notificación: Caso con regresión se envía solo cuando alguien registra a mano un resultado fallido en una ejecución manual. Las ejecuciones reportadas desde CI envían Ejecución fallida o Ejecución completada.

Qué son los commits candidatos y qué no son

Bajo esas listas, Commits candidatos muestra los commits que Qably recibió en pushes entre la ejecución anterior y esta, del más reciente al más antiguo: los cinco más recientes, cada uno con sha corto, primera línea del mensaje, autor, rama y fecha, y un botón para ver los más antiguos. Aparece solo cuando la ejecución tiene al menos una regresión o un arreglo.

Importante: La lista nunca dice qué commit causó la falla. Contiene todos los commits recibidos entre las dos ejecuciones, hayan tocado o no el código detrás del caso que falla.

Cuando ambas ejecuciones reportan el mismo commit, el bloque dice Ambas ejecuciones usaron el mismo commit: el código no cambió, así que revise la prueba y el entorno, y la señal Inestable descrita en cómo leer las señales de un caso.

Qué necesita para funcionar

La lista es tan buena como lo que Qably registró. Deben cumplirse tres condiciones:

El proyecto tiene un repositorio de GitHub conectado, para que Qably reciba sus pushes. Vea el paso 2 del inicio rápido.
Las dos ejecuciones reportan commitSha, un campo de POST /runs/ingest y un parámetro de consulta de POST /runs/ingest/junit. El flujo del paso 4 del inicio rápido no lo envía: agréguelo al paso que reporta (ejemplo tras esta lista).
Los commits se enviaron con push después de conectar el repositorio. Qably reconstruye la lista con los pushes que registró su webhook; no consulta a GitHub ni recupera historial anterior.

Cadena de consulta del paso que reporta

externalId=gha-${{ github.run_id }}-${{ github.job }}&source=github_actions&commitSha=${{ github.event.pull_request.head.sha || github.sha }}

La expresión usa el commit de la punta del pull request y, en un push, github.sha, porque en las compilaciones de pull request github.sha es un commit de fusión temporal que ningún push contiene.

Cuando Qably dice que no lo sabe

Si los pushes registrados no demuestran una cadena desde la ejecución anterior hasta esta, Qably no adivina: el bloque muestra una línea neutral, información y no un error.

Mensaje	Qué significa	Qué hacer
Una de las ejecuciones no informó un commit.	Una de las dos ejecuciones no tiene `commitSha`.	Agréguelo al reporte. Rige desde la siguiente ejecución.
Este proyecto no tiene un repositorio conectado.	No hay un repositorio de GitHub vinculado, así que no hay pushes que leer.	Conecte uno (primera condición).
Un commit de estas ejecuciones no está en los pushes registrados.	Ningún push registrado menciona un commit que reportó una de las ejecuciones.	Busque entregas fallidas en el registro del webhook en GitHub. Reporte un commit enviado con push, no uno temporal como el de fusión de un pull request.
Las ejecuciones provienen de ramas distintas.	El commit anterior solo se registró en ramas donde nunca se registró el de esta ejecución.	No hay nada roto: la ejecución anterior está en otra línea de historial. Las ejecuciones consecutivas de una misma rama sí obtienen lista.
Faltan algunos pushes registrados entre estas ejecuciones.	La cadena está cortada: un push no llegó, un push creó la rama entre las ejecuciones, o el historial supera los 1000 pushes más recientes que Qably lee.	Busque entregas fallidas en el webhook. Los pushes faltantes no se recuperan; lea el historial en GitHub.
El historial se reescribió (force push) entre estas ejecuciones.	Un push forzado reemplazó commits, así que no se puede confiar en los vínculos registrados.	No hay nada que corregir. Lea el historial en GitHub.
La ejecución anterior está en un commit más nuevo que esta.	La ejecución anterior, por hora de inicio, corrió un commit más nuevo que esta.	Es típico al volver a correr un commit antiguo o cuando los pipelines inician fuera de orden. Compare los commits en GitHub.
Hay demasiados commits entre estas ejecuciones para listarlos.	Llegaron más de 100 commits entre las ejecuciones.	Lea el historial en GitHub y reporte con más frecuencia para que las ejecuciones queden más cerca.

Una rutina de cuatro pasos

Abra la ejecución y lea Qué cambió. ¿Los casos de "Empezaron a fallar" comparten un área o es un solo caso?
Lea Commits candidatos, del más reciente al más antiguo, y abra los cercanos al área que falla. Si el bloque dice que no lo sabe, busque el motivo en la tabla anterior.
Corra el caso que falla en su máquina con el commit de esta ejecución y con el de la anterior. Con muchos candidatos, git bisect acota el rango por usted.
Corrija el código o la prueba. En la siguiente ejecución el caso aparece bajo "Se arreglaron". Si sigue cambiando de resultado, trátelo como inestable.