GitHub Code Quality : piloter vos règles de couverture

Les règles de couverture GitHub Code Quality peuvent désormais être gérées par API REST. Une équipe peut donc définir un seuil de couverture de lignes ou une baisse maximale acceptable dans une pull request, puis appliquer le même cadre à plusieurs dépôts. L’intérêt n’est pas de transformer la couverture en objectif isolé : c’est de rendre un niveau de vérification explicite, reproductible et adapté au risque produit.

Ce que l’API rend possible

Jusqu’ici, l’option Restrict code coverage se configurait dans l’interface GitHub. L’API REST permet maintenant de créer, lire et mettre à jour cette condition de ruleset. Concrètement, une organisation peut la décrire dans son outillage d’administration ou son infrastructure-as-code, plutôt que de compter sur une succession de réglages manuels.

GitHub distingue deux intentions : exiger un pourcentage minimal de couverture de lignes, ou refuser une baisse qui dépasse un seuil choisi sur une pull request. La règle suppose que GitHub Code Quality est activé et que les données de couverture sont bien importées. Elle est disponible pour GitHub Team et GitHub Enterprise Cloud, y compris avec résidence des données ; elle ne concerne pas GitHub Enterprise Server.

Une règle de couverture ne remplace pas le jugement

Un pourcentage global ne dit pas si le paiement, une autorisation ou un calcul métier critique est bien testé. À l’inverse, une baisse temporaire peut être légitime lors d’une suppression de code obsolète ou d’une migration. La valeur d’une règle est de signaler un écart et de demander une décision visible, pas de laisser un indicateur unique décider à la place de l’équipe.

Un déploiement progressif en trois étapes

1. Fiabiliser la mesure. Vérifiez que chaque pipeline remonte une couverture comparable et que les branches concernées sont bien celles utilisées pour livrer.
2. Choisir une attente par type de dépôt. Un service critique, une application mobile et une vitrine n’ont pas nécessairement le même seuil ni la même tolérance de baisse.
3. Versionner la politique. Décrivez la règle dans l’outillage qui pilote vos dépôts, testez-la sur un petit périmètre puis observez les exceptions demandées avant de l’étendre.

Relier le signal au parcours qui compte

La bonne question avant de bloquer une pull request reste : quel comportement devient moins vérifié ? Une équipe peut combiner la règle avec des tests ciblés sur les parcours métier, une revue des modifications sensibles et des contrôles de déploiement. Cela évite de multiplier les tests décoratifs uniquement pour atteindre un chiffre.

L’annonce officielle GitHub précise les prérequis et les offres concernées. Avant toute généralisation, testez également les endpoints et le format de règles retenu dans un dépôt non critique.