Un fallo de CI que no significaba realmente que el código estuviera mal desaparece de GitHub. La acción upload-code-coverage de GitHub Code Quality ya no marca como fallido un workflow cuando se ejecuta sobre una rama nueva que todavía no tiene pull request abierto.
GitHub explica en su changelog del 1 de octubre que la API de cobertura necesitaba antes un número de pull request para cualquier push a una rama no predeterminada. Como ese número no existe hasta que se abre el PR, la subida fallaba aunque el workflow fuese correcto.
Ahora la subida se omite en vez de fallar
Cuando una rama no tiene PR asociado, la acción salta la subida de cobertura y deja una explicación en un aviso de Actions y en el resumen del paso. El comportamiento se mantiene en pushes posteriores hasta que exista un pull request.
Los pushes a la rama predeterminada y los eventos de pull request compatibles siguen funcionando como hasta ahora. No hace falta cambiar la configuración existente si el workflow ya escucha los eventos adecuados.
La modificación llega mientras GitHub ajusta varios componentes de Actions. La compañía empezó a aplicar nuevas reglas de retención de ejecuciones, checks y estados, por lo que los equipos están revisando tanto la ejecución como la conservación de datos del CI.
Un detalle importante para workflows solo con push
Abrir un pull request no provoca por sí solo una nueva subida si el workflow está configurado exclusivamente para push. La cobertura se reanudará en el siguiente push de esa rama. Quien quiera cobertura inmediata al abrir el PR debe añadir también el trigger pull_request.
Para equipos pequeños, el cambio reduce falsos fallos y evita que una rama aparezca roja por una limitación de contexto. Esto es especialmente útil cuando la política interna exige CI limpio antes de empezar una revisión.
La infraestructura de ejecución también está evolucionando: Actions Runner Controller 0.15.0 mejora la gestión de flotas de runners y Dependabot puede usar runners específicos en repositorios privados.
Menos ruido en el pipeline
Una alerta de CI debe significar que hay algo que investigar. Cuando un paso falla por no existir todavía un PR, el equipo pierde tiempo diferenciando errores reales de limitaciones de la herramienta. La nueva lógica hace que el estado represente mejor lo que realmente ocurrió.
Para organizaciones con muchos repositorios, esa reducción de ruido se suma a otras mejoras de gobernanza. GitHub permite sincronizar criticidad, ownership y compliance desde un CMDB y ofrece pruebas de Advanced Security en planes Team.
Los equipos que utilizan IA para acelerar desarrollo también están viendo cambios paralelos: HydraFusion puede coordinar varios modelos dentro de VS Code.
Qué revisar hoy
Las empresas no necesitan modificar el workflow por este cambio, pero sí conviene revisar si la cobertura debe ejecutarse al abrir un pull request. Si el objetivo es tener el dato disponible desde el primer momento de la revisión, el trigger del PR debe estar presente.
La modificación es pequeña frente a otras novedades de GitHub, pero mejora una de las cosas más valiosas en CI/CD: que un fallo signifique un fallo real y no una condición esperable del ciclo de trabajo.
Fotografía: Daniil Komov / Pexels.
