GitHub Code Coverage en protection de merge: définir le contrat avant le seuil

Dev
GitHub permet d’utiliser des seuils de coverage et de qualité comme condition de merge. Les équipes doivent préparer baseline, diff coverage, exclusions et rollout.
Un coverage gate utile formalise le risque d’un changement au lieu de sacraliser un pourcentage.

Ce qui s’est passé

GitHub a annoncé le 30 juin 2026 la protection de merge pour les pull requests via GitHub Code Coverage. Un dépôt peut bloquer un PR si les seuils de coverage ou de qualité ne sont pas respectés.

Pourquoi c’est important

L’intérêt est opérationnel: le signal de coverage arrive dans le review flow, puis dans les rulesets ou branch protections, au lieu de rester dans un outil séparé.

Signal communautaire

Les communautés de développeurs restent prudentes: une forte couverture ne prouve pas la qualité, mais laisser la couverture baisser crée une dette réelle. Le rollout doit intégrer ces deux objections.

Impact opérationnel

Séparez la couverture totale de la diff coverage. La première mesure la santé du dépôt; la seconde regarde si le PR ajoute du code non testé.

Liste pratique

Commencez par un soft fail, excluez explicitement generated code, migrations et fixtures, définissez les approbateurs d’exception, puis durcissez progressivement.

Risques

Le risque principal est la fausse confiance. Le coverage gate complète les assertions, les tests d’intégration et la revue humaine; il ne les remplace pas.

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.

Sources

다른 글