docs: record the Sonar gate trap and a no-CI-polling rule in SKILL.md - #34
Merged
Merged
Conversation
Two cross-repo rules learned the hard way during the CI/CD rework. The two SonarCloud checks look redundant and are not. The app-posted "SonarCloud Code Analysis" runs the built-in "Sonar way" gate, which has no new-issue condition - verified against the API, its six conditions are ratings, coverage, duplication and hotspots reviewed. Code smells only move a debt-ratio threshold, so a PR can carry any number of them and still show a green app check while the repo-local "Fail on new SonarCloud issues" step correctly goes red. Custom quality gates are Team/Enterprise-only, so that step cannot be replaced by configuration - it is the only enforcement there is, and deleting it as a duplicate would silently drop the strictest quality rule to nothing. The polling rule is a working-style preference: agents should report the PR link and check name rather than holding a terminal open against a pipeline. AGENTS.md already names this file the canonical copy of the mux skill, so it is where both belong.
|
| Filename | Overview |
|---|---|
| SKILL.md | Clarifies the distinct Sonar checks and adds explicit guidance against polling CI; the previously reported terminology conflict is resolved. |
| docs/repo-governance.md | Replaces ambiguous quality-gate wording with terminology consistent with SKILL.md and the repository workflow. |
Reviews (2): Last reviewed commit: "docs: attribute the zero-new-issue rule ..." | Re-trigger Greptile
Review catch. Two places said "the gate fails on any new issue" without distinguishing the two checks, which is the exact confusion the new SKILL.md rule warns about - it reads as though the app-posted check enforces it, making the repo-local job look redundant. repo-governance.md now describes both checks and which one actually enforces zero new issues. SKILL.md line 58 said the same thing loosely and now points at the detailed rule below it.
|
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.



Two cross-repo rules learned during the CI/CD rework, added to the canonical
muxskill.The two SonarCloud checks are not redundant
They look like duplicates. They are not, and treating them as such would quietly
remove the only quality enforcement the org has.
SonarCloud Code Analysisis posted by Sonar's own GitHub app and runs thebuilt-in Sonar way gate. Queried against the API, its six conditions are:
new_security_ratingnew_reliability_ratingnew_maintainability_ratingnew_coveragenew_duplicated_lines_densitynew_security_hotspots_reviewedThere is no new-issue condition. Ratings are issue-derived but lenient: one
new Bug or Vulnerability fails the gate, while code smells only move a
technical-debt ratio, so a PR can carry any number of them and still pass.
Observed directly on muxlang/mux-compiler#324: 5 new code smells, app check
green, repo-local "Fail on new SonarCloud issues" step correctly red on
the same analysis.
Custom quality gates are Team/Enterprise-only, so the repo-local step cannot be
replaced by configuration. It is the only thing enforcing zero new issues.
Never poll or watch CI
Working-style rule: report the PR link and check name after pushing rather than
holding a terminal open against a pipeline.
Why here
AGENTS.mdalready designates this file the canonical copy of themuxskilland asks that local copies be kept in sync. That had drifted - a local copy was
carrying superseded runtime-resolution guidance describing a cache the compiler
no longer uses. Fixed on this end by symlinking the local copy at this file, so
the canonical version is the only one that exists.
🤖 Generated with Claude Code