Skip to content

chore(ci): remove dead Codecov upload steps + lock pins - #870

Merged
hyperpolymath merged 2 commits into
mainfrom
chore/remove-dead-app-ci-refs
Sep 20, 2026
Merged

hyperpolymath merged 2 commits into
mainfrom
chore/remove-dead-app-ci-refs

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

Removed CI references to apps that are no longer installed on this account/org.

Why this is a fix, not a tidy-up

  • Codecov was uninstalled as a GitHub App, but its action steps remain in workflows.
  • The estate Actions allowlist already pruned 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.
  • Snyk / Codacy / Mergify / ImgBot / CodeFactor are on the estate never-re-add list (standards spec §9, rulings R1/R4/R5).

Changes

  • rhodium-standard-repositories/examples/enterprise-service/.github/workflows/ci.yml — applied
  • rhodium-standard-repositories/satellites/rsr-certifier/.github/workflows/rust-ci.yml — applied

Notes

  • actions.lock entries for the removed actions are deleted in this same commit (the same-PR regen rule in the CI/CD regularisation spec §6.4), so actions-lock-verify sees no drift.
  • Removals are line-exact; no other line was reformatted and no comment was re-wrapped.
  • Historical records (milestone logs, CHANGELOG, audit docs, specs) that describe the removal were deliberately left untouched.
  • The gitar-approved label is intentionally frozen per docs/LABELS.adoc — it is not an active Gitar install, so it stays.

Line-exact removal of dead-app CI references.
@coderabbitai

coderabbitai Bot commented Sep 20, 2026 •

Copy link
Copy Markdown
Contributor

Review Change StackReview Change Stack

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 89530216-b84b-4516-9700-aa2d954aafdc

📥 Commits

Reviewing files that changed from the base of the PR and between b4d50b5 and 801642f.

📒 Files selected for processing (3)
  • .github/workflows/tailscale-connect-reusable.yml
  • config/settings/actions-allowlist.json
  • rhodium-standard-repositories/actions-allowlist/allowed-actions.json
 ______________________________________
< Be a super developer. Go home early. >
 --------------------------------------
  \
   \   \
        \ /\
        ( )
      .( o ).

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: fe068cb8-79d5-4044-b662-78c9a8b1754a

📥 Commits

Reviewing files that changed from the base of the PR and between a087ce5 and b4d50b5.

📒 Files selected for processing (2)
  • rhodium-standard-repositories/examples/enterprise-service/.github/workflows/ci.yml
  • rhodium-standard-repositories/satellites/rsr-certifier/.github/workflows/rust-ci.yml
💤 Files with no reviewable changes (2)
  • rhodium-standard-repositories/examples/enterprise-service/.github/workflows/ci.yml
  • rhodium-standard-repositories/satellites/rsr-certifier/.github/workflows/rust-ci.yml

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.


📝 Summary

Summary by CodeRabbit

  • Chores
    • Updated continuous integration workflows so generated coverage reports are no longer uploaded to an external coverage service.
    • Testing, formatting, linting, security checks, coverage generation and release builds continue to run as before.

Walkthrough

Two Rust CI workflows no longer upload generated coverage reports to Codecov. Their test, formatting, lint, security, coverage generation, and build steps remain unchanged.

Changes

Coverage CI changes

Layer / File(s) Summary
Remove coverage uploads
.github/workflows/ci.yml, .github/workflows/rust-ci.yml
The workflows no longer invoke Codecov upload actions after generating coverage reports. Other CI steps remain unchanged.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~5 minutes

Change: Bug fix

Suggested reviewers: joshuajewell

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarises the main change: removal of obsolete Codecov upload steps and related lock pins from CI workflows.
Description check ✅ Passed The description is directly related to the changes. It explains the removal of obsolete Codecov references, identifies the affected workflows, and provides the reason and implementation details.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

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.

❤️ Share

A rabbit watched the coverage run
The Codecov step was quietly done
Tests still hop
Builds still pop
Clean workflows greet the sun

Comment @coderabbitai help to get the list of available commands.

@hyperpolymath

Copy link
Copy Markdown
Owner Author

Added a commit here: the template allowlist no longer lists codecov/codecov-action@* or snyk/actions@*, both allowlists gain tailscale/github-action@*, and .github/workflows/tailscale-connect-reusable.yml is added so repos can opt into tailnet reachability without inventing their own snippet. Deno/semgrep/send-mail are deliberately left in the template until their workflows are swept.

@sonarqubecloud

Copy link
Copy Markdown

Quality Gate Failed Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

@hyperpolymath
hyperpolymath merged commit bcf9dfa into main Sep 20, 2026
10 of 20 checks passed
@hyperpolymath
hyperpolymath deleted the chore/remove-dead-app-ci-refs branch September 20, 2026 22:23
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 }}
hyperpolymath added a commit that referenced this pull request Sep 20, 2026
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`.
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.
hyperpolymath added a commit that referenced this pull request Sep 20, 2026
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants