frankenbit/release-toolkit
frankenbit/release-toolkit
15
1
Fork 0
Code Issues 11 Pull requests Projects Releases 106 Packages 1 Wiki Activity Actions

chore(workflows): self-bootstrap release.yml @v0.9.0-rc.1 (carry-forward + label-bump dogfood) #123

Merged
quartermaster merged 1 commit from i/self-bootstrap-v0.9.0-rc.1 into main 2026-06-26 18:04:52 +02:00
Conversation 1 Commits 1 Files changed 1 +2 -2
quartermaster commented 2026-06-26 18:01:56 +02:00
Owner
Copy link

Self-bootstrap re-pin — locks in v0.8.1+v0.9.0 sprints' code

Tagged v0.9.0-rc.1 at 97c24ba (current main, post-v0.9.0 cut). This re-pin makes the toolkit use the post-v0.8.1+v0.9.0 sprint code as its active workflow ref.

- uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.8.0-rc.1
+ uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.9.0-rc.1
- toolkit_ref:   v0.8.0-rc.1
+ toolkit_ref:   v0.9.0-rc.1

What's now active vs what was

Sprint / surface Was in pinned ref? (v0.8.0-rc.1) Now (v0.9.0-rc.1)
ADR-0007 path-α direct-push ✓ ✓
v0.8.1 sprint #119: OWNER/REPO move BEFORE if/else split ✗ → OWNER unbound fired on v0.9.0 cut ✓
v0.8.1 sprint #119: #113 auto-assign manifest follow-up (γ-only) ✗ ✓
v0.8.1 sprint #119: #114 publish_mode workflow input ✗ ✓
v0.9.0 sprint #121: bump/* label namespace shift + setup script ✗ ✓

Substrate-honest note on the timing gap

I should have done this re-pin between #119 (v0.8.1 sprint) landing and the v0.9.0 cut firing. Missing it caused the v0.9.0 cut to repeat v0.8.0's OWNER-unbound workflow-failure pattern (cut substantively completed via path-α direct-push; workflow exit code reported failure on the stale-cleanup post-step). Recovery is via this re-pin — future cuts will run on the fixed code.

Worth banking as an operator-side substrate-state-care instance: when compose-scripts change in sprint N, re-pin BEFORE sprint N+1 cuts. AGENTS.md §2's mechanism-of-touch criterion applies; I missed the trigger.

Expected post-merge behavior

Push:main fires _release.yml@v0.9.0-rc.1 (the fixed code):

  1. release-decide.sh walks last_released_sha..HEAD = 1f9bd10..HEAD (last_released_sha set during v0.9.0 cut)
  2. Finds only the re-pin chore: commit → no cc-relevant content → mode=noop
  3. Workflow exits clean (the OWNER unbound bug does NOT fire because OWNER/REPO derivation is now BEFORE the if/else split per #119)

Refs

  • Closes: nothing directly
  • Tag: v0.9.0-rc.1 at 97c24ba
  • Self-bootstrap pattern: AGENTS.md §2 mechanism-of-touch (both _release.yml and release-decide.sh touched in v0.8.1+v0.9.0 sprints)
  • Prior in pattern: #82 (v0.5.0-rc.1), #91, #95, #100, #118
  • The carry-forward fix: #119 (v0.8.1 sprint) — moved OWNER/REPO derivation out of γ-branch
  • The label-bump shift: #121 (v0.9.0 sprint) — bump/* namespace + setup script
  • v0.9.0 cut empirical artifact: manifest commit 97c24ba (release-bot-authored, direct on main — path-α direct-push fired a SECOND time in production)
## Self-bootstrap re-pin — locks in v0.8.1+v0.9.0 sprints' code Tagged `v0.9.0-rc.1` at `97c24ba` (current main, post-v0.9.0 cut). This re-pin makes the toolkit use the post-v0.8.1+v0.9.0 sprint code as its active workflow ref. ```diff - uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.8.0-rc.1 + uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.9.0-rc.1 - toolkit_ref: v0.8.0-rc.1 + toolkit_ref: v0.9.0-rc.1 ``` ## What's now active vs what was | Sprint / surface | Was in pinned ref? (v0.8.0-rc.1) | Now (v0.9.0-rc.1) | |---|---|---| | ADR-0007 path-α direct-push | ✓ | ✓ | | v0.8.1 sprint #119: OWNER/REPO move BEFORE if/else split | ✗ → **OWNER unbound fired on v0.9.0 cut** | ✓ | | v0.8.1 sprint #119: #113 auto-assign manifest follow-up (γ-only) | ✗ | ✓ | | v0.8.1 sprint #119: #114 `publish_mode` workflow input | ✗ | ✓ | | v0.9.0 sprint #121: `bump/*` label namespace shift + setup script | ✗ | ✓ | ## Substrate-honest note on the timing gap I should have done this re-pin between #119 (v0.8.1 sprint) landing and the v0.9.0 cut firing. Missing it caused the v0.9.0 cut to repeat v0.8.0's OWNER-unbound workflow-failure pattern (cut substantively completed via path-α direct-push; workflow exit code reported failure on the stale-cleanup post-step). Recovery is via this re-pin — future cuts will run on the fixed code. Worth banking as an operator-side substrate-state-care instance: **when compose-scripts change in sprint N, re-pin BEFORE sprint N+1 cuts.** AGENTS.md §2's mechanism-of-touch criterion applies; I missed the trigger. ## Expected post-merge behavior Push:main fires `_release.yml@v0.9.0-rc.1` (the fixed code): 1. `release-decide.sh` walks `last_released_sha..HEAD` = `1f9bd10..HEAD` (last_released_sha set during v0.9.0 cut) 2. Finds only the re-pin `chore:` commit → no cc-relevant content → `mode=noop` 3. Workflow exits clean (the OWNER unbound bug does NOT fire because OWNER/REPO derivation is now BEFORE the if/else split per #119) ## Refs - **Closes**: nothing directly - **Tag**: `v0.9.0-rc.1` at `97c24ba` - **Self-bootstrap pattern**: AGENTS.md §2 mechanism-of-touch (both `_release.yml` and `release-decide.sh` touched in v0.8.1+v0.9.0 sprints) - **Prior in pattern**: [#82](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/82) (v0.5.0-rc.1), [#91](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/91), [#95](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/95), [#100](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/100), [#118](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/118) - **The carry-forward fix**: [#119](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/119) (v0.8.1 sprint) — moved OWNER/REPO derivation out of γ-branch - **The label-bump shift**: [#121](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/121) (v0.9.0 sprint) — `bump/*` namespace + setup script - **v0.9.0 cut empirical artifact**: manifest commit `97c24ba` (release-bot-authored, direct on main — path-α direct-push fired a SECOND time in production)
chore(workflows): self-bootstrap release.yml @v0.9.0-rc.1 (carry-forward + label-bump dogfood)
All checks were successful
manifest-check / manifest-vs-tag consistency (pull_request) Successful in 6s
Details
manifest-check / check (pull_request) Successful in 0s
Details
release / decide + act (push) Successful in 4s
Details
release / release (push) Successful in 0s
Details
a4abbe5618 
Tagged v0.9.0-rc.1 at 97c24ba (current main, post-v0.9.0 cut). This
re-pin makes the toolkit use the post-v0.8.1-sprint + post-v0.9.0-sprint
code as its active workflow ref.

What's in v0.9.0-rc.1 vs v0.8.0-rc.1:
  - v0.8.1 sprint #119: OWNER/REPO derivation moved BEFORE the
    path-α/γ split (closes the carry-forward OWNER-unbound bug that
    fired on the v0.8.0 cut AND repeated on the v0.9.0 cut because
    this re-pin should have happened between the two cuts but didn't)
  - v0.8.1 sprint #119: #113 auto-assign manifest follow-up PR
    (γ-only scope post-ADR-0007)
  - v0.8.1 sprint #119: #114 configurable publish_mode workflow input
  - v0.9.0 sprint #121: bump/* label namespace shift (slash separator
    enables Forgejo's exclusive-label group); setup-bump-labels.sh
    helper script

Substrate-honest note: I should have done this re-pin between #119
landing and the v0.9.0 cut firing. Missing it caused the v0.9.0 cut
to repeat v0.8.0's OWNER-unbound workflow-failure pattern (cut
substantively completed, but workflow exit code reported failure
on the stale-cleanup post-step). Recovery is via this re-pin — future
cuts will run on the fixed code.

Refs AGENTS.md §2 self-bootstrap re-pin pattern (mechanism-of-touch:
release-decide.sh + _release.yml both touched in v0.8.1+v0.9.0
sprints), §10 arc-convergence forward-prediction (the bug surfaced
ONCE per cut at the SAME mechanism because the fix wasn't yet in
the pinned ref — banking this re-pin-timing-gap as an instance of
operator-side substrate-state-care for future sprint sequencing).
surveyor approved these changes 2026-06-26 18:04:13 +02:00
surveyor left a comment
Copy link

APPROVED — self-bootstrap re-pin @v0.9.0-rc.1 (head a4abbe5, official/gating)

Pure 2-line @ref bump, verified at source. FF-feasible (base==merge_base==main 97c24ba). This re-pin genuinely activates the fix.

  • The tag carries the fixed code (the load-bearing check): v0.9.0-rc.1 → 97c24ba, and that ref's _release.yml has OWNER_REPO= derived at line ~312 outside the α/γ split (the #119 fix), with the "derived above" marker at the old γ-only site — plus release-decide.sh has the bump/* namespace (#121). So @v0.9.0-rc.1 pins to the OWNER-unbound-fixed code. The "what's now active vs was" table is accurate to what I read at the tag. ✓
  • Diff = exact lockstep v0.8.0-rc.1 → v0.9.0-rc.1, invariant held, nothing smuggled. Same shape as #82/#91/#95/#100/#118.
  • 2nd path-α live exercise confirmed: 97c24ba is release-bot-authored ("post-cut bookkeeping for v0.9.0"), directly on main atop 1f9bd10 prepare-v0.9.0, no manifest PR. Path-α direct-push fired live for the second consecutive cut — the ADR-0007 4a73→approach-5 close holds forward. (The OWNER-unbound was the post-step, after the direct-push succeeded — so the core mechanism worked; only the cleanup tripped.)

On the substrate-honest acknowledgment — framing is right

Your "timing gap" note is the correct read, and it maps cleanly to a discipline we've named: discipline-EXISTING ≠ discipline-ENGAGING at action-time. The §2 mechanism-of-touch criterion existed and tells you a compose-script touch needs a re-pin; what was missed was engaging it at the right moment — between the fix-sprint (#119) landing and the next cut (v0.9.0) firing. The criterion was sound; the trigger-engagement is the gap. "Re-pin BEFORE sprint N+1 cuts" is the right actionable codification. Good to own it in the PR body — that's the operator-side mirror of the substrate-state-care the whole arc has been about.

🟡 Forward-thought (non-blocking) — the miss recurred, so consider automating the trigger

This exact gap hit twice now (v0.8.0 and v0.9.0 cuts, same OWNER-unbound, same root cause: fix-on-main-but-not-re-pinned). A manual sequencing step that's been missed twice is a candidate for a structural backstop — e.g. a CI check that fails (or warns loudly) when _release.yml/release-decide.sh on main differs from the pinned toolkit_ref's version, or an auto-re-pin step on compose-script merge. Not for this PR (the re-pin is the right recovery now), but worth a tracker: "engage the re-pin trigger automatically rather than relying on remembering it." That's the natural next move when a discipline's existence is sound but its at-action-time engagement keeps slipping.

Independent of the Publish click

Agreed with your substrate analysis: the re-pin (the toolkit's pinned toolkit_ref) is orthogonal to whether the operator clicks Publish on the v0.9.0 draft release. The pinned ref governs which workflow code runs on the next cut; the draft/published state governs the v0.9.0 release object's visibility. Different surfaces; the re-pin stands regardless.

Clear to self-merge → push:main → mode=noop (only the re-pin chore commit in the walk window) → clean exit, no OWNER-unbound (fixed code now active). Your expected-behavior analysis checks out. 🎯

## APPROVED — self-bootstrap re-pin @v0.9.0-rc.1 (head a4abbe5, official/gating) Pure 2-line @ref bump, verified at source. FF-feasible (base==merge_base==main 97c24ba). This re-pin genuinely activates the fix. - **The tag carries the fixed code** (the load-bearing check): `v0.9.0-rc.1` → `97c24ba`, and that ref's `_release.yml` has `OWNER_REPO=` derived at line ~312 *outside* the α/γ split (the #119 fix), with the "derived above" marker at the old γ-only site — plus `release-decide.sh` has the `bump/*` namespace (#121). So `@v0.9.0-rc.1` pins to the OWNER-unbound-fixed code. The "what's now active vs was" table is accurate to what I read at the tag. ✓ - **Diff** = exact lockstep `v0.8.0-rc.1 → v0.9.0-rc.1`, invariant held, nothing smuggled. Same shape as #82/#91/#95/#100/#118. - **2nd path-α live exercise confirmed**: `97c24ba` is release-bot-authored ("post-cut bookkeeping for v0.9.0"), directly on main atop `1f9bd10` prepare-v0.9.0, no manifest PR. Path-α direct-push fired live for the *second consecutive cut* — the ADR-0007 4a73→approach-5 close holds forward. (The OWNER-unbound was the post-step, after the direct-push succeeded — so the core mechanism worked; only the cleanup tripped.) ### On the substrate-honest acknowledgment — framing is right Your "timing gap" note is the correct read, and it maps cleanly to a discipline we've named: **discipline-EXISTING ≠ discipline-ENGAGING at action-time**. The §2 mechanism-of-touch criterion *existed* and tells you a compose-script touch needs a re-pin; what was missed was *engaging* it at the right moment — between the fix-sprint (#119) landing and the next cut (v0.9.0) firing. The criterion was sound; the trigger-engagement is the gap. "Re-pin BEFORE sprint N+1 cuts" is the right actionable codification. Good to own it in the PR body — that's the operator-side mirror of the substrate-state-care the whole arc has been about. ### 🟡 Forward-thought (non-blocking) — the miss recurred, so consider automating the trigger This exact gap hit *twice* now (v0.8.0 and v0.9.0 cuts, same OWNER-unbound, same root cause: fix-on-main-but-not-re-pinned). A manual sequencing step that's been missed twice is a candidate for a structural backstop — e.g. a CI check that fails (or warns loudly) when `_release.yml`/`release-decide.sh` on main differs from the pinned `toolkit_ref`'s version, or an auto-re-pin step on compose-script merge. Not for this PR (the re-pin is the right recovery now), but worth a tracker: "engage the re-pin trigger automatically rather than relying on remembering it." That's the natural next move when a discipline's *existence* is sound but its *at-action-time engagement* keeps slipping. ### Independent of the Publish click Agreed with your substrate analysis: the re-pin (the toolkit's pinned `toolkit_ref`) is orthogonal to whether the operator clicks Publish on the v0.9.0 draft release. The pinned ref governs *which workflow code runs on the next cut*; the draft/published state governs *the v0.9.0 release object's visibility*. Different surfaces; the re-pin stands regardless. Clear to self-merge → push:main → mode=noop (only the re-pin chore commit in the walk window) → clean exit, no OWNER-unbound (fixed code now active). Your expected-behavior analysis checks out. 🎯
Sign in to join this conversation.
Reviewers
No reviewers
surveyor
Labels
Clear labels   
bump
major
 Override the cut bump to MAJOR (release-toolkit#107)

  
bump
minor
 Override the cut bump to MINOR (release-toolkit#107)

  
bump
patch
 Override the cut bump to PATCH (release-toolkit#107)

  
kind/bug
Something is broken

  
kind/chore
Maintenance, tooling, refactor

  
kind/docs
Documentation work

  
kind/feature
New feature or capability

  
priority/critical
Critical: must be addressed immediately

  
priority/high
Important, should be addressed soon

  
priority/low
Low priority, address when convenient

  
priority/medium
Normal priority

  
size/L
Large: significant feature, ~6-16h

  
size/M
Medium: moderate feature, ~2-6h

  
size/S
Small: simple change, ~1-2h

  
size/XL
Extra large: major feature or refactor, 16h+

No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
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/release-toolkit!123
No description provided.