How would you block merges when PR coverage drops 2%?

What's really being asked

This question evaluates whether you understand the full pipeline from test execution to merge policy. The interviewer wants to see that you can integrate coverage data into CI/CD and enforce it through version control platform mechanisms. The core concepts are artifact generation, coverage service configuration, and branch protection integration.

The full answer

A strong response walks through four layers in order. First, test instrumentation: your test runner generates a machine-readable coverage report, such as an XML Cobertura file or lcov.info, using tools like pytest-cov, jest, or jacoco. Second, upload step: the CI pipeline pushes that report to a coverage aggregation service. Using Codecov as an example, you install the Codecov CLI or use the official GitHub Action in your workflow file after tests finish. Third, threshold configuration: in a codecov.yml file at the repository root, you define a project status check with target set to auto so it compares against the base commit, and threshold set to 2, allowing the coverage to drop by up to two percentage points before marking the check failed. Fourth, enforcement: in repository settings, you mark the Codecov project status check as required in branch protection rules for the default branch, preventing merges when the check fails.

The mistakes people make

A red flag is suggesting reviewers manually check coverage numbers in PR comments or relying on honor-system policies. Another weak pattern is proposing a custom shell script that diffs two coverage files locally; this is brittle and ignores platform-native status checks. A third mistake is conflating patch coverage, which measures only lines changed in the PR, with project coverage, which measures the whole codebase. The question asks about overall project coverage drop, so the answer must reference the project status check, not patch coverage alone.

What usually comes next

The interviewer may ask how you handle partial uploads or missing coverage from parallel CI jobs, which you solve by merging reports before upload or using Codecov carryforward flags for unchanged modules. They might also ask what happens if the base commit coverage is unreliable, in which case you could switch target from auto to a fixed number like 80. Another follow-up is how to exempt generated code or test utilities, which you do by configuring ignore paths in codecov.yml.

A concrete example

Suppose a Python repository uses pytest. In the GitHub Actions workflow, you run pytest with cov=src and cov-report=xml flags after unit tests. The next step uses the Codecov Action to upload coverage.xml. The codecov.yml sets coverage status project default target auto and threshold 2. When a pull request drops coverage from 85% to 82.5%, Codecov posts a failed status check. Because branch protection requires the Codecov project check to pass, the merge button stays disabled until the developer adds tests or adjusts code.