fix(certifier): stop accepting Codecov config as coverage signal - #873
Merged
Merged
Conversation
Contributor
|
Warning Review limit reachedNext included review available in 58 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…ailscale decision
Owner
Author
|
Corrected my own earlier wording on the O5 row: the sweep shows 1561/85455 are not "resolved with no bypass" — they, plus |
|
hyperpolymath
added a commit
that referenced
this pull request
Sep 20, 2026
Corrects a wrong number I introduced in #873, which auto-merged before I caught it. The sentence being fixed claimed 946600 was live on `67 repo rulesets (17 hyperpolymath, 50 metadatastician)`. That came from a 96-repo sample, and the sample script also read *this table itself* as if it were evidence of live bypass grants. Re-ran the scan over **all** 453 repos (1,026 rulesets, both estates): 1561, 85455 and 946600 appear exactly once each, all on one *disabled* ruleset (`anvomidaviser` id 14968878), which also still has `always` bypass for the maintain role and the three retired rules — so the action there is deletion, not repair. Useful by-product for the CodeRabbit work: on active rulesets the only integration bypass actors are oikosbot (6) and claude (2); dependabot, github-actions, gitguardian, sonarqubecloud and coderabbitai hold none, so CodeRabbit's bypass actor has to be added when it is installed or its auto-fix pushes are blocked by the estate ruleset.
hyperpolymath
added a commit
that referenced
this pull request
Sep 20, 2026
… the O5 row (#878) Follows the Codecov sweep (#870, #873, #874) into the enforcement layer, where the same apps left a deeper residue. **A.** `config/rulesets/Optimus-Extras.json` still defined `code_coverage`, `code_quality`, `required_deployments` and `copilot_code_review` — the four constraints §7.3 retired and the four `scripts/plan-ruleset-constraint-repair.rb` exists to strip. As the only branch-side template in the estate it is why the drift reappears on every manual convergence. Now a single `code_scanning` rule (kept: GitHub-native, no app); `name`/`enforcement`/`bypass_actors` untouched, JSON re-parsed in the script. **B.** Corrects a sentence I merged in #874 — "No active ruleset grants bypass to any uninstalled app". It came from a sweep that trusted `GET /repos/{o}/{r}/rulesets`, whose list payload **omits `rules` and `bypass_actors`**; 1,026 rulesets came back with empty arrays and looked clean. Re-fetched per ruleset (1,036, all 453 repos): gitar-bot 827041 has `always` bypass on the `metadatastician` org ruleset `EstateBranching` (all 43 repos), 946600 on 56 active rulesets, 1561/85455 on 9 each, maintain-role `always` on 53. codecov, codacy, renovate, advanced-security: zero. Two more ids nobody can name (262318, 1658531) also hold `always` on that org ruleset. **C.** Documents that no committed script globs `config/rulesets/`, and that this token's ruleset *writes* are 404 while `POST`/`DELETE` are accepted — so the fix is PUT bodies for an owner session, not a workflow applier that could drop protection in a delete/create gap. Generated plan (96 repo rulesets + the org one, dry-run validated, live re-read guard) is in the audit workspace: `estate-audit/ruleset-repair/apply-ruleset-repair.sh`, same semantics as `plan-ruleset-constraint-repair.rb`. No CI impact: template JSON is consumed by owner-run tooling, and the only repo whose workflow reads `config/rulesets/` is the tag canon, which is untouched.
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.
Two follow-ups to the merged allowlist PR (#870), both about why Codecov kept coming back rather than the references themselves:
rsr-certifieracceptedcodecov.yml/.codecov.yml(and any CI file containing the stringcodecov) as proof of coverage configuration, and its advice text named Codecov first. That made the certifier reward the removed app, so any repo that dropped it could be nudged back. It now accepts the local generators only (tarpaulin / llvm-cov / coverage.py, pluscoverallsconfig which some Elixir repos generate locally).No toolchain in this environment, so the Rust edit is verified by exact-string replacement plus bracket-balance checks, not by
cargo check.