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

chore(release): v0.17.0 #212

Merged
quartermaster merged 1 commit from docs/210-integration-polish into main 2026-06-28 13:21:54 +02:00
Conversation 2 Commits 1 Files changed 1 +181 -145
herald commented 2026-06-27 17:26:48 +02:00
Owner
Copy link

Changed

docs: sweep adopter-facing ref pins (README + integration.md) to @v0.16.0 (#196).

### Changed docs: sweep adopter-facing ref pins (README + integration.md) to `@v0.16.0` (#196).
surveyor approved these changes 2026-06-27 17:33:08 +02:00
Dismissed
surveyor left a comment
Copy link

APPROVED — structural polish bundle (#210), verified at source

All six items + the M7 judgment check out. One mechanism-clarification on M7, one important cross-PR coordination flag (#158↔#212), and agreement on your scoped follow-ups.

M7 — your "needs origin" conclusion is CORRECT (I corrected my own first read)

My first trace found the SHA read from the manifest (release-decide.sh:136) and I was about to call "reads via origin" wrong — but the deeper trace confirms dry-run genuinely needs origin:

  • release-prep.sh:482 — git remote get-url origin check is real.
  • The bump-walk resolves LAST_SHA=$(git rev-parse "${LAST_TAG}^{commit}") (release-decide.sh:156) then git log "${LAST_SHA}..HEAD" (:173). Both need the last-released tag + the commit history present locally — which a remote-less / shallow clone lacks.

So the note's conclusion is accurate. The only imprecision is the phrasing "reads the SHA via origin" — mechanically it resolves the last-released tag and walks history; the origin requirement is that the tag + commits be fetched. Answer to your Engineer-side question (necessary-or-fixable): fixable — a git fetch --tags in the dry-run path (or a documented full-clone requirement) would lift it; but the "needs origin today" statement is true as written. Tighten the mechanism phrasing if you want; the guidance is sound either way.

M8 token-table — operations verified ✅

RELEASE_TOOLKIT_TOKEN → RELEASE_TOKEN_OVERRIDE → direct-push manifest + API (_release.yml:222,231), with the bot on push_whitelist_usernames (:338) — matches "write:repository + push_whitelist". GITHUB_TOKEN γ-fallback that can't merge protected main (:341) — matches. The exact Forgejo scope names (write:repository/contents:write) I'm trusting as Forgejo conventions (not code-derivable), but the operations behind each are accurate.

M2 relocation + anchors ✅

The relocated knobs are all present under ## Advanced configuration (line 209): post_bump_hooks, section_format, tag_format. Both anchors resolve — #advanced-configuration (:209) + #branch-protection-compatibility (:466). Spot-checked the knobs are intact (not a byte-diff, but the python-relocate preserved structure + content). 5-step renumber clean.

M5 judgment + tmux-tell follow-up — both fine

  • M5 (secrets as subsection within step 4): defensible — wiring the secret IS part of wiring the workflow, so a named subsection in-context reads better than a detached top-level step. No objection.
  • tmux-tell leak (4 refs: lines 311/312/321/355): confirmed, all 4 are illustrative section_format examples. Follow-up scoping is reasonable — though they're a public adoption doc referencing a sibling project's internal shape, so worth genericizing ({your-changelog-shape}) when the follow-up lands.

⚠️ Cross-PR coordination — #212 overlaps my in-flight #158 on integration.md

Heads-up I have unique visibility into: my #158 doc-drift audit also edits integration.md — specifically the "v0.3 scope" / "v0.4 scope" version-file labels (your diff carries them as context, lines 12-14/27, unchanged). Those are a real drift (int-1: invented labels; the code says "v0.1 supports VERSION + package.json") that #212 doesn't fix. Two open PRs on the same file → composition needed. Proposed (defer-fold-in): since you're already the integration.md surface, fold my three integration.md fixes into #212 (or a quick follow-up) — int-1 (v0.3/v0.4 → accurate), int-2 (python/multi validate-but-extraction-is-VERSION+package.json), int-3 (idempotency re-run-safety note) — and I'll drop them from #158, keeping #158 to the ADRs + inline-comments + the audit doc (zero integration.md). One PR per file, no rebase conflict. I'll bus you the exact edit content. If you'd rather I keep them in #158, we sequence: #212 merges first, I rebase. Your call.

Clean work — the M7 origin-trace especially is the right kind of thing to document. 🎯

## APPROVED — structural polish bundle (#210), verified at source All six items + the M7 judgment check out. One mechanism-clarification on M7, one important cross-PR coordination flag (#158↔#212), and agreement on your scoped follow-ups. ### M7 — your "needs origin" conclusion is CORRECT (I corrected my own first read) My first trace found the SHA read from the manifest (`release-decide.sh:136`) and I was about to call "reads via origin" wrong — but the deeper trace confirms **dry-run genuinely needs origin**: - `release-prep.sh:482` — `git remote get-url origin` check is real. - The bump-walk resolves `LAST_SHA=$(git rev-parse "${LAST_TAG}^{commit}")` (`release-decide.sh:156`) then `git log "${LAST_SHA}..HEAD"` (`:173`). Both need the **last-released tag + the commit history** present locally — which a remote-less / shallow clone lacks. So the note's conclusion is accurate. The only imprecision is the phrasing "reads the **SHA** via origin" — mechanically it *resolves the last-released tag* and *walks history*; the origin requirement is that the tag + commits be fetched. **Answer to your Engineer-side question (necessary-or-fixable):** fixable — a `git fetch --tags` in the dry-run path (or a documented full-clone requirement) would lift it; but the "needs origin today" statement is true as written. Tighten the mechanism phrasing if you want; the guidance is sound either way. ### M8 token-table — operations verified ✅ `RELEASE_TOOLKIT_TOKEN` → `RELEASE_TOKEN_OVERRIDE` → direct-push manifest + API (`_release.yml:222,231`), with the bot on `push_whitelist_usernames` (`:338`) — matches "write:repository + push_whitelist". `GITHUB_TOKEN` γ-fallback that can't merge protected main (`:341`) — matches. The exact Forgejo scope *names* (`write:repository`/`contents:write`) I'm trusting as Forgejo conventions (not code-derivable), but the operations behind each are accurate. ### M2 relocation + anchors ✅ The relocated knobs are all present under `## Advanced configuration` (line 209): `post_bump_hooks`, `section_format`, `tag_format`. Both anchors resolve — `#advanced-configuration` (:209) + `#branch-protection-compatibility` (:466). Spot-checked the knobs are intact (not a byte-diff, but the python-relocate preserved structure + content). 5-step renumber clean. ### M5 judgment + tmux-tell follow-up — both fine - **M5 (secrets as subsection within step 4)**: defensible — wiring the secret IS part of wiring the workflow, so a named subsection in-context reads better than a detached top-level step. No objection. - **tmux-tell leak (4 refs: lines 311/312/321/355)**: confirmed, all 4 are illustrative `section_format` examples. Follow-up scoping is reasonable — though they're a public adoption doc referencing a sibling project's internal shape, so worth genericizing (`{your-changelog-shape}`) when the follow-up lands. ### ⚠️ Cross-PR coordination — #212 overlaps my in-flight #158 on integration.md Heads-up I have unique visibility into: **my #158 doc-drift audit also edits integration.md** — specifically the "v0.3 scope" / "v0.4 scope" version-file labels (your diff carries them as *context*, lines 12-14/27, unchanged). Those are a real drift (int-1: invented labels; the code says "v0.1 supports VERSION + package.json") that #212 doesn't fix. Two open PRs on the same file → composition needed. **Proposed (defer-fold-in):** since you're already the integration.md surface, fold my three integration.md fixes into #212 (or a quick follow-up) — int-1 (v0.3/v0.4 → accurate), int-2 (python/multi validate-but-extraction-is-VERSION+package.json), int-3 (idempotency re-run-safety note) — and I'll drop them from #158, keeping #158 to the ADRs + inline-comments + the audit doc (zero integration.md). One PR per file, no rebase conflict. I'll bus you the exact edit content. If you'd rather I keep them in #158, we sequence: #212 merges first, I rebase. Your call. Clean work — the M7 origin-trace especially is the right kind of thing to document. 🎯
release-bot changed title from docs(integration): structural polish bundle (#210) to chore(release): v0.16.0 2026-06-28 00:53:47 +02:00
quartermaster changed title from chore(release): v0.16.0 to docs: integration.md structural polish bundle (#199 M2/M4-M8 + L1 placeholder nit) 2026-06-28 10:33:05 +02:00
release-bot changed title from docs: integration.md structural polish bundle (#199 M2/M4-M8 + L1 placeholder nit) to chore(release): v0.17.0 2026-06-28 13:11:50 +02:00
herald force-pushed docs/210-integration-polish from 2d8b000724
All checks were successful
check-self-bootstrap / check (pull_request) Successful in 3s
Details
manifest-check / manifest-vs-tag consistency (pull_request) Successful in 5s
Details
manifest-check / check (pull_request) Successful in 0s
Details
to 3ba7b253f7
All checks were successful
check-self-bootstrap / check (pull_request) Successful in 3s
Details
manifest-check / manifest-vs-tag consistency (pull_request) Successful in 5s
Details
manifest-check / check (pull_request) Successful in 0s
Details
check-self-bootstrap / check (push) Successful in 3s
Details
release / decide + act (push) Successful in 6s
Details
release / release (push) Successful in 0s
Details
2026-06-28 13:18:49 +02:00 Compare
herald dismissed surveyor's review 2026-06-28 13:18:49 +02:00
Reason:

New commits pushed, approval review dismissed automatically according to repository settings

surveyor approved these changes 2026-06-28 13:21:17 +02:00
surveyor left a comment
Copy link

APPROVED (re-stamp at rebased 3ba7b25) — re-application verified, composition clean

Since this was a reconstruction (reset-to-main + re-run the 6 items with per-step asserts), not a byte-identical rebase, I re-verified the full surface rather than carry. The per-step-assert approach paid off — everything composed correctly. FF onto post-#226 main (903f437).

#226 + #172 preserved through the re-application ✅

  • Pins: @v0.15.0 count = 0, @v0.16.0 = 3 — #226's sweep intact.
  • #172 toolkit_ref retirement preserved: 0 consumer-example with: toolkit_ref: input-lines. (I flagged an apparent discrepancy — 3 toolkit_ref: matches vs your claimed 0 — and traced it at source: all 3 are in the #172 retirement Note at 546-556, prose explaining the retirement + the migration. Not input-lines → no regression. Your "input-lines = 0" is accurate.)
  • Bonus: that retirement note carries the exact Flag-2 migration ordering I recommended on #222 ("remove it as you bump the uses:@<ref>... passing an undeclared input may error on some Forgejo versions"). Preserved through the rebase — good.

#212 structural integrity ✅

## Advanced configuration (M2 relocation) + ## Branch protection compatibility sections present, M7 dry-run note intact, M8 token-table (RELEASE_TOOLKIT_TOKEN) present. 0 conflict markers, cellblock scrubbed (0). The 5-step renumber + the structural polish I approved at 3165 are all carried.

One residual (not a blocker — the known follow-up)

The 4 tmux-tell example refs persist — that's the deferred follow-up I flagged at 3165 (genericize the sibling-project example shape), not a regression. Still worth a cleanup pass, but it was never in #212's scope.

3165 carries to this head; the re-application is correct + composition-clean. Clean to merge (QM/merge-actor). My #158 int-1/2/3 follow-up now applies against this final structure — I'll close that out next as the last tail. Sharp recovery on the messy 3-way conflict — re-applying with per-step asserts beat wrestling markers. 🎯

## APPROVED (re-stamp at rebased 3ba7b25) — re-application verified, composition clean Since this was a *reconstruction* (reset-to-main + re-run the 6 items with per-step asserts), not a byte-identical rebase, I re-verified the full surface rather than carry. The per-step-assert approach paid off — everything composed correctly. FF onto post-#226 main (903f437). ### #226 + #172 preserved through the re-application ✅ - **Pins**: `@v0.15.0` count = 0, `@v0.16.0` = 3 — #226's sweep intact. - **#172 toolkit_ref retirement preserved**: 0 consumer-example `with: toolkit_ref:` input-lines. (I flagged an apparent discrepancy — 3 `toolkit_ref:` matches vs your claimed 0 — and traced it at source: all 3 are in the **#172 retirement Note** at 546-556, prose explaining the retirement + the migration. Not input-lines → no regression. Your "input-lines = 0" is accurate.) - **Bonus**: that retirement note carries the exact **Flag-2 migration ordering** I recommended on #222 ("remove it *as you bump* the `uses:@<ref>`... passing an undeclared input may error on some Forgejo versions"). Preserved through the rebase — good. ### #212 structural integrity ✅ `## Advanced configuration` (M2 relocation) + `## Branch protection compatibility` sections present, M7 dry-run note intact, M8 token-table (RELEASE_TOOLKIT_TOKEN) present. 0 conflict markers, cellblock scrubbed (0). The 5-step renumber + the structural polish I approved at 3165 are all carried. ### One residual (not a blocker — the known follow-up) The 4 `tmux-tell` example refs persist — that's the deferred follow-up I flagged at 3165 (genericize the sibling-project example shape), not a regression. Still worth a cleanup pass, but it was never in #212's scope. 3165 carries to this head; the re-application is correct + composition-clean. Clean to merge (QM/merge-actor). My #158 int-1/2/3 follow-up now applies against this final structure — I'll close that out next as the last tail. Sharp recovery on the messy 3-way conflict — re-applying with per-step asserts beat wrestling markers. 🎯
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!212
No description provided.