GitHub Code Coverage merge protection: 数字より先にロールアウト契約を決める

Dev
GitHubでcoverageやcode qualityのしきい値をPRのmerge protectionに使えるようになった。導入前にbaseline、diff coverage、例外、flaky testを決めたい。
coverage gateは品質を保証する魔法の数字ではなく、危険な変更を説明させる運用契約です。

何が起きたか

GitHubは2026年6月30日、GitHub Code Coverageによるpull request merge protectionを発表しました。PRがcoverageまたはcode qualityのthresholdを満たさない場合、mergeを止められます。

なぜ重要か

重要なのは、coverageが外部ダッシュボードの参考値ではなく、rulesetやbranch protectionに接続されるreview上の条件になる点です。

コミュニティの論点

開発者コミュニティではcoverage thresholdへの懸念が長くあります。高い数字は良いテストを保証しませんが、coverage低下を放置するとテスト負債は増えます。

運用への影響

実務ではtotal coverageとdiff coverageを分けるべきです。前者は長期的な健康状態、後者は今回の変更が未検証コードを増やしたかを示します。

チェックリスト

まずsoft failで観察し、main branchのbaselineを保存し、generated codeやmigrationを明示的に除外し、例外承認者を決めます。

リスク

リスクはfalse confidenceとCIの遅さです。coverage gateはassertion品質、integration test、人間の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.

出典

다른 글