GitHub Code Coverage come merge protection: prima il contratto, poi la percentuale

Dev
GitHub consente di usare soglie di coverage e qualità come protezione dei PR. Prima dell’80%, servono baseline, diff coverage, eccezioni e rollout.
Un coverage gate utile rende visibile il rischio, non trasforma la qualità in un numero magico.

Cosa è successo

GitHub ha annunciato il 30 giugno 2026 la merge protection per pull request tramite GitHub Code Coverage. Un PR può essere bloccato se non rispetta soglie di coverage o code quality.

Perché conta

Il punto pratico è che la coverage entra nel flusso di review e nei ruleset, invece di restare un report esterno.

Segnale della community

La community discute da anni questo tema: coverage alta non garantisce qualità, ma regressioni non controllate creano debito nei test.

Impatto operativo

Conviene separare total coverage e diff coverage. La prima descrive la salute storica; la seconda mostra se questo PR aggiunge codice non testato.

Checklist

Partite con soft fail, fissate una baseline, escludete file generati e migrazioni, e definite chi può approvare una discesa.

Rischi

Il rischio è la falsa sicurezza. Il gate non sostituisce assertion utili, test di integrazione e responsabilità nella review.

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.

Fonti

다른 글