GitHub Code Coverage como protección de merge: antes del número, define el contrato
Qué pasó
GitHub anunció el 30 de junio de 2026 merge protection para pull requests mediante GitHub Code Coverage. Un repositorio puede exigir umbrales de cobertura o calidad antes de permitir el merge.
Por qué importa
El cambio importa porque la conversación de cobertura se mueve al flujo de review. El check fallido queda visible en el PR y puede integrarse con rulesets o branch protection.
Señal comunitaria
La señal de la comunidad es conocida: la cobertura alta no garantiza calidad, pero permitir regresiones sin límite acumula deuda de tests. La adopción debe reconocer ambas cosas.
Impacto operativo
El modelo más sano separa cobertura total y diff coverage. La primera muestra salud histórica; la segunda pregunta si este cambio añade código sin protección.
Checklist
Empieza con soft fail, documenta exclusiones para código generado y migraciones, define quién puede aprobar una caída y sube el umbral de forma gradual.
Riesgos
El riesgo es convertir el número en teatro. Un gate útil apunta a archivos afectados, líneas sin cubrir y ruta de excepción, no solo a un porcentaje rojo.
Rollout checklist
• Start with a baseline, not an ideal target.
• Separate total coverage from diff coverage.
• Document exclusions and exception approvers.
• Use soft fail before hard enforcement.
Fuentes
- GitHub Changelog: GitHub Code Coverage merge protection for pull requests
- GitHub Docs: Setting pull request thresholds for code quality and coverage
- GitHub Docs: Setting up code coverage for your repository
- GitHub Docs: About GitHub Code Quality
- GitHub Docs: About status checks
- GitHub Docs: About protected branches
- GitHub Docs: Interpreting code quality results