ci: adopt the fleet release-PR healer - #130
Merged
Merged
Conversation
Release PRs here arrive with their required contexts absent rather than red: release-please creates them with GITHUB_TOKEN and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever. The healer lives in forkwright/.github; this file only asks for it. The permissions block is load-bearing rather than boilerplate: for a called workflow the caller's permissions are a CAP, never a default it may exceed, so the customary `contents: read` alone would leave the healer unable to approve a single run -- and the only symptom would be a release that stayed stuck.
forkwright
added a commit
that referenced
this pull request
Aug 26, 2026
## Finding
Cargo.toml requires `bindgen = "0.72"` and `rand = { version = "0.9",
features = ["small_rng"] }`, but Cargo.lock (before this branch) still
resolved `bindgen 0.71.1` and, for the `decode`, `kernels`, and `praxis`
crates specifically, `rand 0.8.7` — even though those three all declare
`rand.workspace = true`. PR 128 bumped the manifest and said so in its
own body: "Cargo.lock — Deliberately untouched and needs regenerating."
Three merges have landed since (#129, #130, #132) without anyone
regenerating it.
## Evidence
Verified at `origin/main` before regenerating:
- `Cargo.toml:33` — `bindgen = "0.72"`; `Cargo.toml:59` — `rand = {
version = "0.9", features = ["small_rng"] }`.
- `crates/decode/Cargo.toml:13`, `crates/kernels/Cargo.toml:25`,
`crates/praxis/Cargo.toml:20` — all `rand.workspace = true`.
- `Cargo.lock:64-65` — `bindgen` resolved to `0.71.1`.
- `Cargo.lock:254`, `:509`, `:732` — `decode`/`kernels`/`praxis` each
listing `"rand 0.8.7"` as a dependency, while `Cargo.lock` separately
already carried `rand 0.9.5` (used by another workspace member).
- `crates/hipcore/Cargo.toml:16` — `bindgen.workspace = true`, and
hipcore is the repo's only bindgen consumer (confirmed in PR 128's
body).
- `cargo metadata --locked` against the unmodified lock was not
attempted destructively; the regeneration below was verified with `cargo
metadata --locked` afterward (see Desired correction) rather than a full
build, per this task's no-build constraint.
## Why this matters
A `--locked` build (what CI and any reproducible build actually run)
resolves dependencies strictly from the lock, not the manifest. With the
manifest requiring bindgen 0.72 / rand 0.9 but the lock still pinning
bindgen 0.71.1 / rand 0.8.7 for three crates, a `--locked` build is
asking for a resolution the lock cannot supply and fails — exactly the
gap PR 128 named and deferred, now three merges stale.
## Desired correction
Regenerated the stale entries only, without a full build:
```
cargo update -p decode -p kernels -p praxis -p bindgen
```
Result, verified against `cargo metadata --locked` (exit 0, lock now
satisfies the manifest):
- `bindgen` 0.71.1 → 0.72.1 (only entry that changed version).
- `rand 0.8.7` and its now-solely-referenced transitives — `rand_chacha
0.3.1`, `rand_core 0.6.4`, `getrandom 0.2.17`, `wasi
0.11.1+wasi-snapshot-preview1` — all drop out of the lock entirely.
`decode`, `kernels`, and `praxis` now resolve against the `rand 0.9.5`
already present in the lock for the rest of the workspace, so the two
parallel `rand` lines collapse to one.
- Nothing else in the dependency graph moved — this was a targeted `-p`
update against the two named crates' consumers, not a blanket `cargo
update`. Full lock diff is 65 lines (9 insertions, 56 deletions),
entirely accounted for by the above.
No CI job or check-run name changes — this PR touches only `Cargo.lock`.
Done when: `Cargo.lock` resolves `bindgen ^0.72` and a single `rand
^0.9` line with no other package version changed, and `cargo metadata
--locked` succeeds.
Co-authored-by: forkwright <cody@forkwright.com>
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.
Finding
Release PRs in this repo arrive with their required contexts absent rather than red.
release-pleasecreates its PR withGITHUB_TOKEN, and GitHub raises no workflow-triggeringevents for that token, so branch protection holds a PR with a missing context forever — nothing to
re-run, nothing to approve.
Evidence
Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733,
gnomon#68) sat 8 days at
mergeStateStatus: BLOCKEDwith an emptystatusCheckRollupwhile their workflow runs waited at
action_required.aletheia has carried the only healer for months. A file-existence check found
release-pr-checks.yml404 in all 17 other release-please repos, and nothing visible frominside any of them revealed the gap.
Why this matters
A missing check is worse than a failing one. A red check advertises itself; an absent one looks
exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears
to be waiting on CI.
Desired correction
Adopt the reusable healer (
forkwright/.github#56). This file asks for it and declares nothingabout how it works, so it cannot drift from the other adopters.
Done when: a subsequent release PR here reaches a non-empty
statusCheckRollupwithout a humanapproving runs by hand.
The permissions block is load-bearing
Not the usual boilerplate. For
workflow_callthe caller'spermissionsis a cap — a calledworkflow can only downgrade the token, never upgrade it. A caller declaring the customary
contents: readalone would leave the healer unable to approve a single run, and the only symptomwould be a release that stayed stuck.
Proven, not assumed
The whole path was exercised on akroasis before this rollout:
Actions: writeconfirmed present in the reusable's job token, so the caller's grant does reachit (run 32982564877).
GITHUB_REPOSITORYresolves to the caller — the healer reported#465 at b75af1a6f,akroasis's own release PR, while running from
forkwright/.github.workflow_runtrigger fired automatically on release-please completion and superseded amanual dispatch via
cancel-in-progress, exactly as designed.GITHUB_TOKEN+actions: writeapproving a genuinely held run:201, and the run movedaction_required→in_progress(probed on zetesis run 31286567826). No PAT and no reposecret are required — an assertion to the contrary lived unexamined in aletheia's copy for
months and is false.