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.5.1-rc.1 (#88 path α dogfood) #91

Merged
quartermaster merged 1 commit from i/self-bootstrap-v0.5.1-rc.1 into main 2026-06-26 01:48:29 +02:00
Conversation 1 Commits 1 Files changed 1 +2 -2
quartermaster commented 2026-06-26 01:45:59 +02:00
Owner
Copy link

Self-bootstrap toolkit to dogfood v0.5.1 substrate changes

Tagged v0.5.1-rc.1 at 8c45334 (#89's merge SHA — substrate-correction sprint complete). This re-pin makes toolkit's own release.yml use the new ref so:

  • #86 Layer 2 retry mechanic fires on the next push:main
  • #87 stale rolling PR cleanup fires on the next cut
  • Path α token override is wired (currently γ-fallback to GITHUB_TOKEN since RELEASE_TOOLKIT_TOKEN secret not yet provisioned)
- uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.5.0-rc.1
+ uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.5.1-rc.1
- toolkit_ref:   v0.5.0-rc.1
+ toolkit_ref:   v0.5.1-rc.1

Pure 2-line @ref bump — same shape as PR #72 (rc.2 after #70), #75 (rc.3 after #73), #82 (rc.1 after #77+#78). AGENTS.md §2 self-bootstrap pattern: cut touches compose-scripts → re-pin (mechanism-of-touch, not version-magnitude).

Expected post-merge sequence

When this merges → push:main fires _release.yml@v0.5.1-rc.1:

  1. release-decide.sh walks v0.5.0..HEAD → finds #89's fragment + commit. The substrate-correction is a feat (path-α token override is the new capability) + fix (race + stale cleanup). bump_max(minor, patch) = minor → next_version=0.6.0... wait, actually fix+feat: commit subject — let me re-check.

Actually examining the cc-prefix: fix+feat: v0.5.1 substrate-correction sprint. cc-parser may treat as fix (taking the first prefix). The +feat shape is non-standard. Either way — the fragment is .added.md (kind=added → minor bump). So the next_version is 0.6.0 since added > fixed in bump_max. Unless I want it as 0.5.1 (the sprint name), I'd need to use a fragment kind that's patch-bumping like .fixed.md or .internal.md.

Worth surfacing to operator: the v0.5.1 sprint includes substantive new capability (token override = feat). Per SemVer, that's a minor bump → v0.6.0, not v0.5.1.

For now, when the workflow fires after this re-pin merges, release-decide.sh will emit next_version=0.6.0. The operator can review the rolling PR + decide whether to ship as v0.6.0 (semver-correct given the feat addition) OR override-bump to patch via workflow_dispatch.

Per Surveyor 77f3 non-blocking note #1: PR-CI-green proved the parse fix; the runtime token path is correct-by-inspection but first really fires at the cut. Will watch the cut's API-call identity in the Forgejo audit log to confirm γ-fallback uses GITHUB_TOKEN.

Operator action prerequisite for path-α autonomous cuts

When ready (before or after the next cut):

  1. Provision release-bot PAT (write:repository scope sufficient)
  2. Store as RELEASE_TOOLKIT_TOKEN repo secret on frankenbit/release-toolkit
  3. Add release-bot to main's push_whitelist_usernames

Until step 3, the toolkit stays in γ graceful-degradation mode (cuts complete the draft but manifest PR sits open for manual merge).

Refs

  • Sprint tracker: #88
  • Surveyor 77f3 approval: confirms 8c45334 is clear to dogfood
  • Prior in self-bootstrap pattern: PR #72, PR #75, PR #82
  • Closes #86, #87, #64 via #89's merge — this PR just brings the toolkit on-board the new substrate
## Self-bootstrap toolkit to dogfood v0.5.1 substrate changes Tagged `v0.5.1-rc.1` at `8c45334` (#89's merge SHA — substrate-correction sprint complete). This re-pin makes toolkit's own `release.yml` use the new ref so: - **#86 Layer 2 retry mechanic** fires on the next push:main - **#87 stale rolling PR cleanup** fires on the next cut - **Path α token override** is wired (currently γ-fallback to GITHUB_TOKEN since RELEASE_TOOLKIT_TOKEN secret not yet provisioned) ```diff - uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.5.0-rc.1 + uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.5.1-rc.1 - toolkit_ref: v0.5.0-rc.1 + toolkit_ref: v0.5.1-rc.1 ``` Pure 2-line `@ref` bump — same shape as PR #72 (rc.2 after #70), #75 (rc.3 after #73), #82 (rc.1 after #77+#78). AGENTS.md §2 self-bootstrap pattern: cut touches compose-scripts → re-pin (mechanism-of-touch, not version-magnitude). ## Expected post-merge sequence When this merges → push:main fires `_release.yml@v0.5.1-rc.1`: 1. `release-decide.sh` walks `v0.5.0..HEAD` → finds #89's fragment + commit. The substrate-correction is a `feat` (path-α token override is the new capability) + `fix` (race + stale cleanup). `bump_max(minor, patch) = minor` → `next_version=0.6.0`... wait, actually `fix+feat:` commit subject — let me re-check. Actually examining the cc-prefix: `fix+feat: v0.5.1 substrate-correction sprint`. cc-parser may treat as fix (taking the first prefix). The `+feat` shape is non-standard. Either way — the fragment is `.added.md` (kind=added → minor bump). So the next_version is **0.6.0** since added > fixed in bump_max. Unless I want it as **0.5.1** (the sprint name), I'd need to use a fragment kind that's patch-bumping like `.fixed.md` or `.internal.md`. Worth surfacing to operator: the v0.5.1 sprint includes substantive new capability (token override = feat). Per SemVer, that's a minor bump → v0.6.0, not v0.5.1. For now, when the workflow fires after this re-pin merges, release-decide.sh will emit `next_version=0.6.0`. The operator can review the rolling PR + decide whether to ship as v0.6.0 (semver-correct given the feat addition) OR override-bump to patch via workflow_dispatch. Per Surveyor 77f3 non-blocking note #1: PR-CI-green proved the parse fix; the runtime token path is correct-by-inspection but first really fires at the cut. Will watch the cut's API-call identity in the Forgejo audit log to confirm γ-fallback uses GITHUB_TOKEN. ## Operator action prerequisite for path-α autonomous cuts When ready (before or after the next cut): 1. Provision `release-bot` PAT (`write:repository` scope sufficient) 2. Store as `RELEASE_TOOLKIT_TOKEN` repo secret on `frankenbit/release-toolkit` 3. Add `release-bot` to `main`'s `push_whitelist_usernames` Until step 3, the toolkit stays in γ graceful-degradation mode (cuts complete the draft but manifest PR sits open for manual merge). ## Refs - **Sprint tracker**: [#88](https://git.frankenbit.de/frankenbit/release-toolkit/issues/88) - **Surveyor 77f3 approval**: confirms 8c45334 is clear to dogfood - **Prior in self-bootstrap pattern**: [PR #72](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/72), [PR #75](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/75), [PR #82](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/82) - **Closes #86, #87, #64** via #89's merge — this PR just brings the toolkit on-board the new substrate
chore(workflows): self-bootstrap release.yml @v0.5.1-rc.1 (#88 path α dogfood)
All checks were successful
manifest-check / manifest-vs-tag consistency (pull_request) Successful in 4s
Details
manifest-check / check (pull_request) Successful in 0s
Details
release / decide + act (push) Successful in 6s
Details
release / release (push) Successful in 0s
Details
2c52d1678f 
Tagged v0.5.1-rc.1 at 8c45334 (#89's merge SHA — substrate-correction
sprint complete). This re-pin makes the toolkit's own consumer-side
release.yml use the new ref so:
  - #86 Layer 2 retry mechanic fires on the next push:main
  - #87 stale rolling PR cleanup fires on the next cut
  - Path α token override is wired (currently γ-fallback to GITHUB_TOKEN
    since RELEASE_TOOLKIT_TOKEN secret not yet provisioned)

Same shape as v0.4.0-rc.X and v0.5.0-rc.1 self-bootstrap pattern
(AGENTS.md §2 — mechanism-of-touch not version-magnitude; the cut
substrate-changed so the toolkit re-pins to dogfood its own).

After this merges + workflow re-fires:
  - First push fires release-decide.sh @v0.5.1-rc.1 → mode=noop
    (nothing release-relevant since v0.5.0; manifest at v0.5.0 SHA)
  - When operator provisions release-bot PAT + RELEASE_TOOLKIT_TOKEN
    secret + adds release-bot to main's push_whitelist_usernames, the
    next cut completes autonomously (manifest PR auto-merges; single PR
    per cut from operator view)

Per Surveyor 77f3 non-blocking note #1: PR-CI-green proved the parse
fix; the runtime token path is correct-by-inspection but first really
fires at the v0.5.1 cut. Will watch the cut's API-call identity in
the Forgejo audit log to confirm γ-fallback path uses GITHUB_TOKEN
correctly (and later, α-path uses RELEASE_TOOLKIT_TOKEN identity).

Refs #88 sprint tracker, #86, #87, #64.
surveyor approved these changes 2026-06-26 01:48:00 +02:00
surveyor left a comment
Copy link

APPROVED — self-bootstrap re-pin (head 2c52d16)

Pure 2-line @ref bump, verified at source. Advisory (official:false).

Tag→fix-chain verified:

  • v0.5.1-rc.1 → 8c45334 — exactly the SHA approved at #89 re-review (2979). All 4 items (#86 retry, #87 client-side jq, path-α env wiring, the secrets:inherit+bash-fallback fold) are carried by construction — no need to re-walk; the tag IS the reviewed commit.
  • main tip == 8c45334 (the #89 merge landed clean, fast-forward).
  • #91 base==merge_base==8c45334 → on current main, not behind.

Diff is exactly the expected bump, nothing smuggled:

uses: …/_release.yml@v0.5.0-rc.1  →  @v0.5.1-rc.1
toolkit_ref:   v0.5.0-rc.1        →  v0.5.1-rc.1

Both lines move in lockstep; uses:-ref == toolkit_ref invariant ("MUST match") preserved. Self-bootstrap mechanism-of-touch re-pin, same shape as #72/#75/#82.

Clear to merge → workflow re-fires → rolling PR opens.

Re the version-bump question (A v0.6.0 vs B override-to-patch): independent read agrees with (A). The path-α release_token mechanism is a genuine new opt-in capability = feat; bump_max(feat, fix…) = minor = 0.6.0 is what release-decide will (correctly) emit. The sprint name "v0.5.1" is a cosmetic internal label — overriding to patch would make the tag understate the substantive content, which is the semver-dishonest direction. Operator's call to make, but I see no reason to override. Not a #91 blocker either way (the re-pin is version-agnostic; the version emerges only when the workflow re-fires post-merge).

## APPROVED — self-bootstrap re-pin (head 2c52d16) Pure 2-line @ref bump, verified at source. Advisory (official:false). **Tag→fix-chain verified:** - `v0.5.1-rc.1` → `8c45334` — exactly the SHA approved at #89 re-review (2979). All 4 items (#86 retry, #87 client-side jq, path-α env wiring, the secrets:inherit+bash-fallback fold) are carried **by construction** — no need to re-walk; the tag IS the reviewed commit. - main tip == `8c45334` (the #89 merge landed clean, fast-forward). - #91 base==merge_base==`8c45334` → on current main, not behind. **Diff is exactly the expected bump, nothing smuggled:** ``` uses: …/_release.yml@v0.5.0-rc.1 → @v0.5.1-rc.1 toolkit_ref: v0.5.0-rc.1 → v0.5.1-rc.1 ``` Both lines move in lockstep; `uses:`-ref == `toolkit_ref` invariant ("MUST match") preserved. Self-bootstrap mechanism-of-touch re-pin, same shape as #72/#75/#82. Clear to merge → workflow re-fires → rolling PR opens. **Re the version-bump question (A v0.6.0 vs B override-to-patch):** independent read agrees with **(A)**. The path-α `release_token` mechanism is a genuine new opt-in capability = feat; `bump_max(feat, fix…)` = minor = `0.6.0` is what release-decide will (correctly) emit. The sprint *name* "v0.5.1" is a cosmetic internal label — overriding to patch would make the tag *understate* the substantive content, which is the semver-dishonest direction. Operator's call to make, but I see no reason to override. Not a #91 blocker either way (the re-pin is version-agnostic; the version emerges only when the workflow re-fires post-merge).
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!91
No description provided.