chore(ci): remove dead Codecov upload steps + lock pins - #870
Conversation
Line-exact removal of dead-app CI references.
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (3)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (2)
💤 Files with no reviewable changes (2)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 SummarySummary by CodeRabbit
WalkthroughTwo Rust CI workflows no longer upload generated coverage reports to Codecov. Their test, formatting, lint, security, coverage generation, and build steps remain unchanged. ChangesCoverage CI changes
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Bug fix Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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. A rabbit watched the coverage run Comment |
|
Added a commit here: the template allowlist no longer lists |
|
| steps: | ||
| # Pinned per estate policy (SHA pins everywhere); refresh with actions-lock. | ||
| - name: Connect to Tailscale | ||
| uses: tailscale/github-action@v4 |
| - name: Connect to Tailscale | ||
| uses: tailscale/github-action@v4 | ||
| with: | ||
| oauth-client-id: ${{ secrets.TS_OAUTH_CLIENT_ID }} |
Two follow-ups to the merged allowlist PR (#870), both about *why* Codecov kept coming back rather than the references themselves: 1. `rsr-certifier` accepted `codecov.yml` / `.codecov.yml` (and any CI file containing the string `codecov`) 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, plus `coveralls` config which some Elixir repos generate locally). 2. The registry doc recorded three integration ids as 'unresolved (owner decision O5)'. 1561 and 85455 are now positively resolved (no matching app, no bypass), leaving only 946600 = Codex MCP. No toolchain in this environment, so the Rust edit is verified by exact-string replacement plus bracket-balance checks, not by `cargo check`.
… 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.
…ials (#880) Fixes three defects in the reusable workflow I added in #870 — found by re-reading my own file against the estate's rules, not by a complaint. 1. **The pin.** The header comment says "SHA pins everywhere" and the step said `uses: tailscale/github-action@v4`. Now `780049a30b6ff5c378a9e7b389d15ece7a204888 # v4.1.3`. Worth knowing: the action also publishes a moving `v4` tag, and as of 2026-09-20 `v4` points at **v4.1.2**, not v4.1.3 — so `@v4` resolves to a commit nobody reviewed. (`git ls-remote`, no API needed.) 2. **The lockfile.** Pinning a `uses:` ref to 40 hex is exactly what makes `.githooks/validate-actions-lock.sh` require a lock entry (it only checks SHA-pinned refs; §6.4 demands regeneration in the same PR), so the entry ships in this commit rather than as a follow-up red build. 3. **Opt-in must be safe before the secrets exist.** The old version failed red for any repo calling it without `TS_OAUTH_*`, which made "wire Tailscale in" and "keep CI green" mutually exclusive. The connect step is now gated on credential presence and skips with a warning; `require: true` restores a hard failure for repos that want it, and the job exposes `outputs.connected` so a dependent job can assert it instead of silently running off-tailnet. ## Verification - Workflow YAML parses; asserted on the parsed tree: `steps[1].uses == tailscale/github-action@780049a…`, `steps[1].if == "steps.gate.outputs.ready == 'true'"`, the gate step sees `secrets.TS_OAUTH_CLIENT_ID`, and `inputs.require.default is False`. - `actions.lock` re-parses (`yaml.safe_load`) with `workflows['.github/workflows/tailscale-connect-reusable.yml'] == ['tailscale/github-action@780049a…']`. - Estate hooks run locally against a full clone: `validate-actions-lock` ✅ (24 SHA-pinned refs / 24 lock keys), `validate-permissions` ✅, `validate-spdx-workflows` ❌ **pre-existing** — it exits 1 on `rhodium-standard-repositories/satellites/**` missing SPDX headers (untouched here); my first draft of this body claimed all four passed, which was wrong. ## A pre-existing bug this PR deliberately does not fix `.githooks/validate-sha-pins.sh` has two defects, and they are not the same one: * the `STAGED_FILES` path (pre-commit) works and does flag unpinned refs; * the repo-wide fallback is dead: `find … -path '*/.github/workflows/*.yml'` requires a leading directory, so a root-level `.github/workflows/x.yml` never matches, the loop body never runs, and the hook prints "All workflow actions are SHA-pinned" having inspected zero files; * and both paths test the *file*, not the *line* — `grep -q 'uses: …@[a-f0-9]'` means one pinned ref excuses every unpinned one in that workflow. Measured with the fixed hook on current main: **26 unpinned `uses:` refs in `.github/workflows/`, 68 across the repo including the vendored `rhodium-standard-repositories/**` copies.** This PR takes its own line out of that set (0 flagged for it, verified by running the fixed hook against both versions of the file). The corrected hook is supplied as `githooks-validate-sha-pins.fix.patch` in the audit workspace: anchored per-line matching (`^[[:space:]]*(- )?uses:`), the `*.github/workflows/*` pattern, local `./` action paths exempt, and a `grep -n`-derived `file:line` message. It was checked against an independent per-line count in Python (68 = 68, no misses, no extras) and `git apply --check` clean. Deliberately not in this PR: landing it makes 68 pre-existing refs red across standards, which is a sweep of its own, not a side effect of a Tailscale pin — and the same hook ships in other repos. ## CI on this PR `Repo self-tests` on the head: the five failing test scripts are unrelated and pre-existing — the same counts appear on the parent commit (14/1, 6/3, 4/5; two others need ruby, unavailable in this environment) and an A/B of the tree with my files removed returns identical numbers. `uses ⊆ actions.lock` and `Lockfile self-consistency` are green.




Removed CI references to apps that are no longer installed on this account/org.
Why this is a fix, not a tidy-up
codecov/codecov-action@*(standards/config/settings/actions-allowlist.json->pruned_from_live_2026_09_02), so a workflow still calling it fails at job start instead of quietly no-op-ing.standardsspec §9, rulings R1/R4/R5).Changes
rhodium-standard-repositories/examples/enterprise-service/.github/workflows/ci.yml— appliedrhodium-standard-repositories/satellites/rsr-certifier/.github/workflows/rust-ci.yml— appliedNotes
actions.lockentries for the removed actions are deleted in this same commit (the same-PR regen rule in the CI/CD regularisation spec §6.4), soactions-lock-verifysees no drift.gitar-approvedlabel is intentionally frozen perdocs/LABELS.adoc— it is not an active Gitar install, so it stays.