ci(gc): gc-native-roots had never completed a run; one arm on PRs

[proggeramlug]

The measurement

gc-native-roots has never completed a single run.

workflow	completed / last 20
test.yml	3
gc-ratchet	2
gc-root-dominance	2
gc-native-roots	0

40 of 40 queued, oldest sitting nine hours.

Why

Four runner classes — macos-14, windows-latest, ubuntu-latest, ubuntu-24.04-arm — fanned out on every push to every branch. Two of those are the scarcest GitHub offers. With ~20 of its own runs competing for them it cannot drain, and I confirmed cancelling doesn't fix it: I cancelled 39 runs and the queue was back to 10 within minutes, because merge rate outpaces drain rate.

A gate that never executes is the purest form of CLAUDE.md's fourth failure mode — it cannot fail, because it cannot run. Every PR in the campaign that built this gate displayed it as "pending": an assertion nobody had ever evaluated. That includes the deep-stack probe, the liveness gate, and the aarch64-Linux arm.

The change

PRs run the ubuntu-latest arm only. main and workflow_dispatch keep all four.

ubuntu-latest is the PR arm on purpose: plentiful runners, and it exercises the least-redundant path — x86-64 roots resolve through the CFA-derived SP base (#7349), which neither the aarch64 x29 chain walk nor Windows' RtlVirtualUnwind shares.

The cost, stated rather than buried

A break confined to macOS, Windows or aarch64-ELF now surfaces on main instead of on the PR. That is a real loss. It is worth taking while the alternative is surfacing nowhere.

gc-native-roots-complete reads the matrix job's aggregate result, so it remains a stable context regardless of arm count — which is what makes promoting it to required possible at all. Right now it cannot be promoted, because it has never been green even once.

Summary by CodeRabbit

• Chores

  • Updated native-root validation workflows to run the full platform matrix on the main branch and on demand.
  • Pull requests now run the Ubuntu x86-64 validation arm, providing faster feedback while preserving comprehensive checks on the main branch.

• Documentation

  • Added changelog documentation describing the workflow coverage and aggregate completion result used for branch protection.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: ab1633ad-f237-4f0f-ba71-47640ab58eaf

📥 Commits

Reviewing files that changed from the base of the PR and between f4506d8 and bd72c63.

📒 Files selected for processing (2)

• .github/workflows/gc-native-roots.yml
• changelog.d/7386-gc-native-roots-never-runs.md

---

📝 Walkthrough

Walkthrough

The gc-native-roots workflow now runs only the Ubuntu x86-64 arm for pull requests. Main-branch and manual runs execute all four native-root runner shapes. A changelog entry documents the scheduling policy and aggregate completion result.

Changes

Native-root CI scheduling

Layer / File(s)	Summary
Event-dependent runner matrix .github/workflows/gc-native-roots.yml, changelog.d/7386-gc-native-roots-never-runs.md	The workflow selects Ubuntu x86-64 for pull requests and all four runner shapes for main and manual runs. The changelog records the coverage policy and aggregate completion result.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• PerryTS/perry#7324: Modifies the same workflow's native-root matrix.
• PerryTS/perry#7344: Adjusts runner coverage in the same workflow.
• PerryTS/perry#7349: Adjusts the same workflow's runner matrix and completion dependencies.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description explains the problem and change, but it omits the required Changes, Related issue, Test plan, Screenshots, and Checklist sections.	Add the template sections and document the verification performed, related issue status, screenshots/output status, and required checklist confirmations.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the CI workflow, its completion problem, and the reduced PR matrix coverage.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
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.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/gc-native-roots-never-runs

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[proggeramlug]

Closing this — the premise is wrong, and I'd rather retract it than quietly rewrite it.

What I claimed

gc-native-roots has never completed a single run — 40 of 40 queued.

What is actually true

120 of the last 200 runs completed. My query used --limit 20/--limit 40, which returns the newest runs — and the newest were all freshly-queued. The completed history was outside the window the whole time.

That is the same window artifact I hit earlier today with a "88 queued, 0 in progress" reading, caught, and said so. I then walked straight back into it and put the result in a PR body and a changelog fragment. Once is a mistake; twice is a lesson about not trusting a paginated listing to answer a question about history.

The real failure

The main run at 8d7364b60 did complete, and failed on all four arms for a reason that has nothing to do with runner supply:

##[error]no matched opt+clang pair under /usr/lib/llvm-22/bin
          — RS4GC cannot run, and silently skipping it is exactly
            the gate that cannot fail

The gate refused to run vacuously, which is the behaviour it was built to have. That is already being fixed in #7384 and #7388.

What that means for this PR

The matrix reduction here was justified entirely by a starvation that isn't happening. Shipping it would trade real macOS/Windows/aarch64-ELF PR coverage for a problem I measured wrong — and would leave a false explanation sitting in a workflow comment, which is precisely how #7321's wrong cause survived into an issue and a job name.

If PR-side CI cost turns out to be worth trimming, that should be its own change with its own measurement. Not this one.