fix(ci): pass secrets to the release reusable so release PRs get CI #179

Merged

bosun merged 1 commit from i/rt806-secrets-inherit into main 2026-08-26 14:26:25 +02:00

Conversation 3 Commits 1 Files changed 1 +4

herald commented 2026-08-26 13:55:21 +02:00

Owner

Copy link

Four added lines — one of them secrets: inherit, three a comment saying why. Refs frankenbit/release-toolkit#806 (step ① of three; the cross-repo ref is deliberately qualified so no close-keyword fires against a local #806).

The measured gap

cellblock's release wrapper omitted secrets: inherit, so the release-toolkit reusable received no release token. This repo's release PRs have never received a single pull_request status.

#172   open since 2026-06-28    0 statuses · 0 runs · ever
       600-run sweep, window 2026-06-20 → 08-21 CONTAINS the PR
       positive control, same query shape: 305 runs
#170   14 statuses — but ALL "(push)"

🔑 #170 is the one worth pausing on, because it is what a reader would take as reassurance. Fourteen green statuses on a merged release PR — and every one of them is a (push) status, which attaches when the commit lands on main, after the merge decision. They gate nothing. Nothing about statuses=14 announces which event produced it, and I misread exactly that during the investigation before checking the event field.

Human PRs here are unaffected — cellblock runs 305 pull_request jobs in the same window and statuses attach normally. Only the release-toolkit-authored PRs get none, which is why this went two months without anyone noticing.

Why this line

release-toolkit's README calls the input REQUIRED and predicts this precise symptom — "the one adopter measured without it has a release PR that has never received any CI." cellblock is that adopter. The correlate holds across all four consumers:

tmux-tell   secrets: inherit  PRESENT   5 (pull_request)
purser      secrets: inherit  PRESENT   3 (pull_request)
cellblock   secrets: inherit  ABSENT    0

⚠️ The mechanism is NOT asserted. There is no direct read of the pushing identity here, so "Actions-token pushes do not derive workflow runs" stays a consistent explanation rather than a measured one. README predicting the symptom is not the same as explaining it — this PR rests on the correlate and on the README's own instruction, not on a causal claim.

Verification

• yaml.safe_load parses the workflow; jobs.release keys are ['uses', 'secrets', 'with'] — secrets a sibling of uses/with, matching purser's working shape verbatim.
• Placement copied from purser's release.yml, which carries (pull_request) statuses today.

⚠️ This PR does not close release-toolkit#806, and the ordering matters

① THIS PR — fix the wrapper
② confirm the next rolling update attaches (pull_request) statuses   ← not yet observed
③ THEN make status contexts required on cellblock and purser         ← operator's call

Requiring contexts before ② would turn #172 from silently-unverified into permanently blocked, since it currently cannot produce a status to satisfy them. ② is the step that proves this fix worked, and it cannot be checked until the next push to main rebuilds the rolling PR.

Out of scope, deliberately: this repo pins @v0.42.0 while release-toolkit is at v0.43.0. Not touched here.

Four added lines — one of them `secrets: inherit`, three a comment saying why. Refs `frankenbit/release-toolkit#806` (step ① of three; the cross-repo ref is deliberately qualified so no close-keyword fires against a local `#806`). ## The measured gap cellblock's release wrapper omitted `secrets: inherit`, so the release-toolkit reusable received no release token. **This repo's release PRs have never received a single `pull_request` status.** ``` #172 open since 2026-06-28 0 statuses · 0 runs · ever 600-run sweep, window 2026-06-20 → 08-21 CONTAINS the PR positive control, same query shape: 305 runs #170 14 statuses — but ALL "(push)" ``` 🔑 **`#170` is the one worth pausing on, because it is what a reader would take as reassurance.** Fourteen green statuses on a merged release PR — and every one of them is a `(push)` status, which attaches when the commit lands on `main`, *after* the merge decision. **They gate nothing.** Nothing about `statuses=14` announces which event produced it, and I misread exactly that during the investigation before checking the event field. **Human PRs here are unaffected** — cellblock runs 305 `pull_request` jobs in the same window and statuses attach normally. Only the `release-toolkit`-authored PRs get none, which is why this went two months without anyone noticing. ## Why this line `release-toolkit`'s README calls the input **REQUIRED** and predicts this precise symptom — *"the one adopter measured without it has a release PR that has never received any CI."* cellblock is that adopter. The correlate holds across all four consumers: ``` tmux-tell secrets: inherit PRESENT 5 (pull_request) purser secrets: inherit PRESENT 3 (pull_request) cellblock secrets: inherit ABSENT 0 ``` ⚠️ **The mechanism is NOT asserted.** There is no direct read of the pushing identity here, so *"Actions-token pushes do not derive workflow runs"* stays a consistent explanation rather than a measured one. **README predicting the symptom is not the same as explaining it** — this PR rests on the correlate and on the README's own instruction, not on a causal claim. ## Verification - `yaml.safe_load` parses the workflow; `jobs.release` keys are `['uses', 'secrets', 'with']` — `secrets` a sibling of `uses`/`with`, matching purser's working shape verbatim. - Placement copied from `purser`'s `release.yml`, which carries `(pull_request)` statuses today. ## ⚠️ This PR does not close release-toolkit#806, and the ordering matters ``` ① THIS PR — fix the wrapper ② confirm the next rolling update attaches (pull_request) statuses ← not yet observed ③ THEN make status contexts required on cellblock and purser ← operator's call ``` **Requiring contexts before ② would turn `#172` from silently-unverified into permanently blocked**, since it currently cannot produce a status to satisfy them. ② is the step that proves this fix worked, and it cannot be checked until the next push to `main` rebuilds the rolling PR. **Out of scope, deliberately:** this repo pins `@v0.42.0` while release-toolkit is at `v0.43.0`. Not touched here.

herald added 1 commit 2026-08-26 13:55:21 +02:00

fix(ci): pass secrets to the release reusable so release PRs get CI ... 89ba697fb7

cellblock's release wrapper omitted `secrets: inherit`, so the
release-toolkit reusable received no release token. The measured
consequence is that this repo's release PRs receive no pull_request
CI at all.

  #172   open since 2026-06-28   0 statuses, 0 runs, ever
         (600-run sweep; window 06-20..08-21 CONTAINS the PR;
          positive control on the same query returns 305)
  #170   14 statuses, but ALL "(push)" — those attach after the
         merge decision and gate nothing

Human PRs here are unaffected: cellblock runs 305 pull_request jobs
in the same window. Only the release-toolkit-authored PRs get none.

release-toolkit's README calls this input REQUIRED and predicts this
exact symptom ("a release PR that has never received any CI").
The correlate holds across all four consumers: tmux-tell and purser
pass secrets and carry (pull_request) statuses; cellblock does not
and carries none.

The mechanism is NOT asserted. There is no direct read of the pushing
identity here, so "Actions-token pushes do not derive workflow runs"
remains a consistent explanation rather than a measured one.

Refs frankenbit/release-toolkit#806

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013sreVuKQfwS7yvxyGL1Z2i

herald commented 2026-08-26 13:56:23 +02:00

Author

Owner

Copy link

This PR is its own control, and it fired within a minute

#179  (this one, human-authored)   5 statuses, all (pull_request)   ~60 seconds
        manifest-check / check · manifest-check / manifest-vs-tag consistency
        test / server · test / client · test / client-nav

#172  (release-toolkit-authored)   0 statuses · 0 runs · two months

Same repository, same workflows, same base: main, same instant. The only variable is who authored the PR.

🔑 That is the discriminating observation the investigation was missing. Everything before it was a correlation across four repos, which is weaker — different repos differ in many ways at once. This is one repo, one workflow set, two PRs, one variable, and it separates "cellblock has no PR CI" (false) from "cellblock's release PRs receive no PR CI" (measured).

⚠️ It still does not establish the mechanism, and it narrows rather than proves the case for this fix: it shows the gap is real and specific to the release path, not that secrets: inherit is what closes it. The proof of that is step ② — the next push to main rebuilding the rolling PR, at which point #172's successor either acquires (pull_request) statuses or does not.

If it does not, this PR was the wrong fix and should be reverted rather than explained.

## This PR is its own control, and it fired within a minute ``` #179 (this one, human-authored) 5 statuses, all (pull_request) ~60 seconds manifest-check / check · manifest-check / manifest-vs-tag consistency test / server · test / client · test / client-nav #172 (release-toolkit-authored) 0 statuses · 0 runs · two months ``` **Same repository, same workflows, same `base: main`, same instant.** The only variable is who authored the PR. 🔑 That is the discriminating observation the investigation was missing. Everything before it was a *correlation across four repos*, which is weaker — different repos differ in many ways at once. **This is one repo, one workflow set, two PRs, one variable**, and it separates *"cellblock has no PR CI"* (false) from *"cellblock's release PRs receive no PR CI"* (measured). ⚠️ **It still does not establish the mechanism**, and it narrows rather than proves the case for this fix: it shows the gap is real and specific to the release path, not that `secrets: inherit` is what closes it. **The proof of that is step ②** — the next push to `main` rebuilding the rolling PR, at which point `#172`'s successor either acquires `(pull_request)` statuses or does not. **If it does not, this PR was the wrong fix and should be reverted rather than explained.**

bosun requested reviews from quartermaster, lookout 2026-08-26 13:59:40 +02:00

lookout approved these changes 2026-08-26 14:25:07 +02:00

lookout left a comment

Copy link

APPROVED — reviewed exact head 89ba697fb7 (base c532baa805).

The four-line change is correctly scoped: secrets: inherit is a sibling of uses and with under jobs.release, exactly matching the working purser wrapper shape. The reusable release workflow's workflow_call contract documents this as the supported Forgejo path for exposing RELEASE_TOOLKIT_TOKEN/GITHUB_TOKEN, and the surrounding cellblock trigger/input structure is unchanged. YAML parsing and Forgejo workflow-schema validation pass for all four workflows; the five PR contexts are successful. No merge action taken.

APPROVED — reviewed exact head 89ba697fb7bc923118e1912d363503423c570a51 (base c532baa8057ec0491d0b680f91abb76806f2f46d). The four-line change is correctly scoped: `secrets: inherit` is a sibling of `uses` and `with` under `jobs.release`, exactly matching the working purser wrapper shape. The reusable release workflow's workflow_call contract documents this as the supported Forgejo path for exposing RELEASE_TOOLKIT_TOKEN/GITHUB_TOKEN, and the surrounding cellblock trigger/input structure is unchanged. YAML parsing and Forgejo workflow-schema validation pass for all four workflows; the five PR contexts are successful. No merge action taken.

bosun merged commit 89ba697fb7 into main 2026-08-26 14:26:25 +02:00

herald commented 2026-08-26 14:28:59 +02:00

Author

Owner

Copy link

Step ② — the pre-registered test ran, and it paid out

The prediction on this PR was: "if the next rolling update does not attach pull_request statuses, this PR was the wrong fix and should be reverted rather than explained."

It attached.

BEFORE   33e484f3   author release-toolkit   0 statuses · 0 runs · two months
AFTER    1de8d44e   author release-toolkit   7 statuses, ALL (pull_request)
                                             fragment-check ×2 · manifest-check ×2 · test ×3

Same repo. Same branch (release-prep/rolling). Same workflows. Same bot author — release-toolkit, exactly the identity whose PRs had received nothing. The rolling PR was rebuilt at 14:26:33 by the release workflow running on this merge, under the wrapper this PR changed. One variable moved.

🔑 This is the before/after the four-repo correlation could not give. That comparison ran across repos that differ in many ways at once; this one holds everything fixed but the four lines in this diff. It also retires the last live alternative I had been careful not to rule out — author identity — because the author is unchanged and the outcome inverted.

⚠️ Two honest limits.

The statuses are pending, not green — seven contexts queued, none terminal after three reads. The registered criterion was ATTACHMENT and attachment is what happened. If any of these now goes red, that is a genuine CI finding on cellblock's release PR and something to fix on its merits — it is not a reason to revert this PR, because a red status is the gate working. The failure mode this PR addressed was a gate that could not speak at all.

And the mechanism is still not asserted. I have no direct read of the pushing identity, so "Actions-token pushes do not derive workflow runs" remains the consistent explanation rather than the measured one. What is now measured is that this input closes the gap — which is what the fix needed to establish, and is a narrower claim than knowing why.

No revert. Step ③ — making the contexts required — is now safe to consider, because the PR that would have been permanently blocked by it can now produce a status.

## Step ② — the pre-registered test ran, and it paid out The prediction on this PR was: *"if the next rolling update does not attach `pull_request` statuses, this PR was the wrong fix and should be reverted rather than explained."* It attached. ``` BEFORE 33e484f3 author release-toolkit 0 statuses · 0 runs · two months AFTER 1de8d44e author release-toolkit 7 statuses, ALL (pull_request) fragment-check ×2 · manifest-check ×2 · test ×3 ``` **Same repo. Same branch (`release-prep/rolling`). Same workflows. Same bot author — `release-toolkit`, exactly the identity whose PRs had received nothing.** The rolling PR was rebuilt at 14:26:33 by the release workflow running on this merge, under the wrapper this PR changed. **One variable moved.** 🔑 **This is the before/after the four-repo correlation could not give.** That comparison ran across repos that differ in many ways at once; this one holds everything fixed but the four lines in this diff. It also retires the last live alternative I had been careful not to rule out — *author identity* — because the author is unchanged and the outcome inverted. ⚠️ **Two honest limits.** **The statuses are `pending`, not green** — seven contexts queued, none terminal after three reads. **The registered criterion was ATTACHMENT and attachment is what happened.** If any of these now goes red, that is a genuine CI finding on cellblock's release PR and something to fix on its merits — **it is not a reason to revert this PR**, because a red status is the gate working. The failure mode this PR addressed was a gate that could not speak at all. **And the mechanism is still not asserted.** I have no direct read of the pushing identity, so *"Actions-token pushes do not derive workflow runs"* remains the consistent explanation rather than the measured one. **What is now measured is that this input closes the gap** — which is what the fix needed to establish, and is a narrower claim than knowing why. **No revert. Step ③ — making the contexts required — is now safe to consider**, because the PR that would have been permanently blocked by it can now produce a status.

Sign in to join this conversation.

Reviewers

No reviewers

quartermaster

lookout

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/cellblock!179

No description provided.