fix(ci): enforce non-zero coverage gate threshold (closes #589) - #601
Merged
Conversation
s2x
force-pushed
the
feat/issue-589-coverage-gate-threshold
branch
from
July 28, 2026 19:31
f3c4940 to
9a7b405
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Closes #589
The CI coverage gate was present in name only: the threshold was
0.0(trivially green at the measured ~82.17% coverage) and the same check ran twice per matrix leg. This PR makes the gate effective.Changes
composer.json(coverage:check) — 80% leaves ~2.2pp headroom against the observed 82.17%, while the measured 0.04pp per-leg spread makes flaky failures impossible.github/workflows/tests.yamlnow callscomposer coverage:checkonly; the verbatimphp bin/check-coverage.php var/coverage.xml 0.0duplicate is gone, so the threshold lives in exactly one placeCheck coverage thresholdstep is restricted viaif:to the lowest supported matrix leg (PHP 8.2 / Symfony 6.4.*); per-leg coverage differs by ~0.04pp so the remaining eight gates were wasted signal. Per-leg coverage reports are still uploaded as artifacts (if: always()preserved)ciaggregation job's "advisory initially" comment now states the advisory mode is intentional (runner timing is too variable to gate merges on)CoverageCiGateTestnow asserts: single gate invocation tied to the correct step, the 8.2/6.4.* leg condition, no directcheck-coverage.phpcall in the workflow, upload step keepsif: always(), and a non-zero threshold defined incomposer.jsondocs/workflow.mdstep 7 andCONTRIBUTING.mdnow state the 80% floor and where it is defined, so contributors learn about it before CI tells themNot implemented (explicitly optional in the issue): the coverage ratchet. 80.0 is the recommended safe first step; a ratchet can follow separately.
Changelog
Added under
[Unreleased]→Fixed: make the CI coverage gate effective (threshold 80% defined once incomposer.json, duplicate removed, single-leg gate).Code Review
Gate failure demonstration
The gate was demonstrated to fail correctly by a temporary commit (now removed) that excluded three covered test directories (
tests/Command,tests/Phar,tests/Supervisor) from the PHPUnit suite. Coverage dropped from ~82% to 68.21%, and the gate failed on the single 8.2 / 6.4 leg:Failing run (8.2/6.4 leg): https://github.com/crazy-goat/workerman-bundle/actions/runs/30379541493/job/90343929802
All other 8 matrix legs stayed green (the gate only runs on the designated leg),
LintandBenchmarkpassed, and the coverage report artifact still uploaded (if: always()). The temporary commit was removed via force-push; the branch now contains only the three implementation commits.Note for reviewer
#597 also touches
.github/workflows/tests.yaml(per its author's comment on #589) — whichever lands second should rebase.