Los desencadenadores

Un workflow declarado con on: push se ejecuta en cada envío, en cada rama, incluso cuando el commit solo toca el archivo README.md. En un equipo de cinco personas, eso supone rápidamente varios cientos de ejecuciones por semana, la mayoría de las cuales no verifican nada útil. El problema no es solo el coste en minutos facturados: es la cola de espera. Cuando veinte ejecuciones inútiles ocupan los runners, la que bloquea una fusión urgente espera detrás de ellas.

El caso más costoso es más discreto. Haces tres commits seguidos en una rama de trabajo: una corrección, un olvido, una errata. GitHub lanza tres ejecuciones completas en paralelo, de las cuales las dos primeras prueban un estado del código que nadie fusionará jamás. Llegarán hasta el final, ocuparán runners y su resultado se ignorará. Elegir bien los desencadenadores y saber cancelar es lo que separa una cadena rápida de una que acaba siendo esquivada.

push y pull_request: el duplicado clásico

Estos dos eventos se parecen, pero no prueban lo mismo. push prueba el contenido de la rama tal como está. pull_request prueba, por defecto, una fusión simulada entre la rama de origen y la rama de destino: un commit de fusión efímero que no existe en ningún repositorio. Es precisamente el estado que importa antes de una fusión, y lo que permite detectar un conflicto semántico: dos modificaciones válidas por separado pero incompatibles entre sí.