Skip to content

patchThreshold and patchFailUnder for PR diff coverage threshold control#636

Open
Yasu-umi wants to merge 1 commit into
k1LoW:mainfrom
Yasu-umi:feature/patch-threshold
Open

patchThreshold and patchFailUnder for PR diff coverage threshold control#636
Yasu-umi wants to merge 1 commit into
k1LoW:mainfrom
Yasu-umi:feature/patch-threshold

Conversation

@Yasu-umi
Copy link
Copy Markdown

@Yasu-umi Yasu-umi commented Mar 4, 2026

First of all, thank you for providing and maintaining this great OSS. I use octocov in my projects and really appreciate its features and quality.

This Pull Request adds a feature to control CI behavior based on patch (PR diff) coverage threshold. With this, CI can be failed automatically if the coverage of the patch falls below a specified threshold, making octocov even more useful for code review and quality assurance in pull requests.

Main changes

  • Add patchThreshold and patchFailUnder to the coverage section in config (octocov.yml) for PR diff coverage threshold control.
  • If diff coverage is below patchThreshold and patchFailUnder is true, octocov diff will exit with code 1 (fail CI).
  • All related code comments and README documentation are in English.

Example config

coverage:
  acceptable: 80%
  patchThreshold: 70% # Patch coverage threshold for PR diff
  patchFailUnder: true # Fail CI if under threshold (false: only warn)

@k1LoW
Copy link
Copy Markdown
Owner

k1LoW commented Mar 4, 2026

@Yasu-umi

Thank you for the PR and for using octocov!

The functionality you're looking for can actually be achieved with the existing coverage.acceptable: configuration. It already supports a diff variable that represents the difference in overall coverage between the current and previous reports.

For example:

coverage:
  acceptable: diff >= 0%
diff:
  datastores:
    - local://.octocov
  • diff >= 0% — fails CI if coverage decreases at all
  • diff >= -1% — fails CI if coverage drops by more than 1%

You can also combine it with an absolute threshold:

coverage:
  acceptable: current >= 80% && diff >= 0%

When the condition is not met, octocov exits with code 1 and reports an error message, which is the same behavior this PR aims to add.

Also, one note on the implementation: the PR uses the name "patch coverage" (coverage of the lines changed in the PR), but dr.Coverage.Diff is actually the overall coverage percentage difference between two reports, not the per-changed-line coverage. These are different concepts.

@Yasu-umi
Copy link
Copy Markdown
Author

Yasu-umi commented Mar 4, 2026

@k1LoW Thank you for your feedback!

I understand now that the current diff variable in octocov only represents the overall coverage difference, not the coverage of the lines changed in the PR ("patch coverage"). What I am looking for is the actual patch coverage, i.e., the coverage of only the lines added or modified in the pull request.

Since coverage reports alone do not contain information about which lines were changed, it seems that calculating patch coverage would require combining coverage data with git diff information.

I would like to implement this feature, but I am wondering what would be the best approach. For example, would it make sense to implement patch coverage calculation as an octocov feature that only works on GitHub Actions (where git diff information is available)? Or is there a recommended way to combine coverage data and git diff to achieve this?

Any advice or suggestions would be greatly appreciated!

@k1LoW
Copy link
Copy Markdown
Owner

k1LoW commented Mar 6, 2026

I understand what you want to achieve.

Introducing patch_current, patch_prev, and patch_diff variables in the acceptable section might be a good idea. Additionally, using the GitHub API, which we rely on heavily, rather than Git, would be preferable (Does not affect the checkout status of the repository on the CI).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants