Análisis incremental en una solicitud de cambios

Un flujo de trabajo de análisis puede lanzarse cuando se abre o actualiza una solicitud de cambios (evento pull_request). La documentación de GitHub recomienda que ese análisis se haga sobre el commit de fusión de la solicitud, no sobre la cabeza de la rama: da resultados más eficientes y más fieles a lo que quedará en la rama principal. Los repositorios con cola de fusión añaden el evento merge_group para que también se analicen al entrar en la cola.

Esto se ve en el flujo de la solicitud: el comentario del paso de descarga del código lo dice.

Lo que la solicitud introduce se ve comparando dos listas: las alertas de la rama principal antes de fusionar y las del commit de fusión. Una alerta que está en la segunda y no en la primera es nueva; la solicitud la causa y a ella se le pide que la corrija.

Compara los dos archivos de la carpeta alertas.

La comparación también funciona al revés: una alerta que estaba en la rama principal y ya no está en el commit de fusión la corrigió la solicitud (o la movió fuera del código analizado, que habría que comprobar). Es una buena noticia que conviene registrar, porque el equipo ve el efecto de lo que corrige.

La descripción de la solicitud dice qué archivos toca.

Las alertas que existían antes de la solicitud y siguen después no son culpa suya. Aparecen en el informe completo del commit de fusión, pero no deben frenarla: de lo contrario nadie podría fusionar nada hasta limpiar el pasado, y el equipo acabaría desactivando el control. Esas alertas pertenecen al tablero de deuda de seguridad, con su propio plazo.

El análisis de una solicitud solo cubre lo que su configuración permite. Con paths-ignore se excluyen carpetas; con languages se eligen los lenguajes. Un cambio en una carpeta excluida llega a la rama sin pasar por el análisis. En api-pedidos se excluyen pruebas y docs, y la solicitud 77 añade un archivo nuevo dentro de pruebas.