👷 ci(sonar): enforce the SonarCloud quality gate in CI - #20
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
OD-3 set continue-on-error on the sonarqube job so an ERROR quality gate could
not veto the very lanes (E4-S01, E4-S02) that were remediating it, with an
explicit instruction to revisit once the gate went green. It went OK on
2026-08-06 after Automatic Analysis was disabled and CI analysis actually ran
(new_duplicated_lines_density 4.6 -> 0.0, new_coverage 93.6).
Two independent holes had to close, since either alone is a false sense of
safety:
- continue-on-error swallowed hard scanner failures. It hid an exit 3
("running CI analysis while Automatic Analysis is enabled") for a full day
while the workflow reported success.
- the scan was fire-and-forget. Without sonar.qualitygate.wait the job went
green the moment the report was uploaded, so a gate flipping to ERROR would
never have failed anything. An earlier revision of this commit removed only
the first and claimed the gate was blocking; that claim was false.
Also wires hack/test/*.sh into task check via a new guards task. Ten config
regression guards existed but nothing ever ran them, so "guarded by" was
aspirational across the whole repo.
Fork PRs receive no secrets, so the scan step self-skips via the SONAR_TOKEN
gate rather than failing. The real cost is that CI now hard-couples to
sonarcloud.io availability for in-repo branches; that is the intended trade.
konih
force-pushed
the
lane/sonar-required-gate
branch
from
August 6, 2026 14:32
92f44ec to
1b83a68
Compare
konih
changed the title
|
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
1 participant
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.
What
continue-on-error: truefrom thesonarqubejob inci.yaml.sonar.qualitygate.wait=truetosonar-project.properties.hack/test/sonar_blocking_gate_test.sh, and wires allhack/test/*.shintotask checkvia a newguardstask.Why
OD-3 made the Sonar gate non-blocking so an ERROR gate could not veto the lanes (E4-S01, E4-S02) remediating it, with an explicit instruction to revisit once it went green. It went green on 2026-08-06:
new_duplicated_lines_densitynew_coveragenew_security_hotspots_reviewedThe earlier diagnosis was wrong: the ERROR was not residual duplication. SonarCloud Automatic Analysis was enabled, which is mutually exclusive with CI analysis (scanner
exit 3every run) and ignoressonar-project.properties— so E4-S02's test exclusions had never been applied and the figure was frozen on a stale baseline.Two holes, not one
The first revision of this PR removed only
continue-on-errorand claimed in its subject that the gate was blocking. That was false, and an independent review caught it:sonarqube-scan-actionis fire-and-forget, so the job went green on upload and an ERROR gate would still have failed nothing. Both halves are needed:continue-on-error→ a scanner failure fails the job (this is what hid the exit 3 for a day);sonar.qualitygate.wait=true→ an ERROR quality gate fails the job.Guards were never run
grep -rn 'hack/test'acrossTaskfile.ymland.github/workflows/returned nothing: ten regression guards existed and nothing executed them, so every "guarded by …" claim in this repo was aspirational. Now wired intotask check.Evidence
origin/maintree → RED on both assertions (continue-on-error: true still present,sonar.qualitygate.wait=true missing); GREEN on this branch.task checkexit 0 — coverage 92.4% (floor 90), gitleaks no leaks, pinned-actions ok (35 refs), 10/10 guards ok.Risk
Fork and Dependabot PRs receive no secrets → the existing
SONAR_TOKENgate makes the scan step self-skip rather than fail. The real, accepted cost: CI for in-repo branches now hard-couples tosonarcloud.ioavailability — a transient outage or flakydownload-artifactreds the PR where it was previously swallowed.Not in scope
mainhas no branch protection and no rulesets (404 /[]), so "blocking" means "the workflow goes red", not "the merge is prevented". Makingsonarqubea required check is a separate governance decision — raised in the INBOX for the operator.