chore(release): v0.57.1 #1157

Merged

bosun merged 2 commits from release-prep/rolling into main 2026-09-05 03:05:48 +02:00

Conversation 4 Commits 2 Files changed 27 +68 -57

release-bot commented 2026-09-05 01:40:41 +02:00

Member

Copy link

Changelog density — clean

• PASS — check 7 (sentence length): all sentences ≤ 25 words. Lists, tables and blockquotes are measured too (#632).
• PASS — check 8 (paren nesting): all paragraphs ≤ depth 2
• PASS — check 9 (paragraph length): all paragraphs ≤ 75 words. Lists, tables and blockquotes are measured too (#632).

Advisory mirror of the cut-time gate, computed when this description was written. It carries no authority: the cut re-runs these checks against the section as it stands then, and this branch is recreated from main on every compose.

Added

None.

Changed

None.

Fixed

• wrappers: Discover preserves directory read errors, distinguishing unreachable paths from readable directories with no matching wrappers (#1084)
• release: the goreleaser workflow builds the pipeline rt before the step that runs it (#1112)
• fragment-check: the optional coverage control now protects the complete skip disclosure, including its required-mode remedy (#1145)

Removed

None.

Deprecated

None.

Upgrade

None.

Internal

• ci: regenerate the .gitea workflow twins left stale by the v0.57.0 post-cut bookkeeping (#1112)

<!-- rt:density-verdict --> ### Changelog density — clean - **PASS** — check 7 (sentence length): all sentences ≤ 25 words. Lists, tables and blockquotes are measured too (#632). - **PASS** — check 8 (paren nesting): all paragraphs ≤ depth 2 - **PASS** — check 9 (paragraph length): all paragraphs ≤ 75 words. Lists, tables and blockquotes are measured too (#632). _Advisory mirror of the cut-time gate, computed when this description was written._ _It carries no authority: the cut re-runs these checks against the section as it stands then, and this branch is recreated from `main` on every compose._ <!-- /rt:density-verdict --> ### Added None. ### Changed None. ### Fixed - **wrappers**: Discover preserves directory read errors, distinguishing unreachable paths from readable directories with no matching wrappers (#1084) - **release**: the goreleaser workflow builds the pipeline `rt` before the step that runs it (#1112) - **fragment-check**: the optional coverage control now protects the complete skip disclosure, including its required-mode remedy (#1145) ### Removed None. ### Deprecated None. ### Upgrade None. ### Internal - **ci**: regenerate the `.gitea` workflow twins left stale by the v0.57.0 post-cut bookkeeping (#1112)

release-bot added 1 commit 2026-09-05 01:40:41 +02:00

chore(release): prepare v0.57.1 ... 14b94c3938

Generated by release-toolkit rt prep.

Tracker: frankenbit/release-toolkit#1

release-bot force-pushed release-prep/rolling from 14b94c3938 to c70f680e92 2026-09-05 01:45:10 +02:00 Compare

release-bot force-pushed release-prep/rolling from c70f680e92 to e556aa32e7 2026-09-05 02:20:58 +02:00 Compare

release-bot force-pushed release-prep/rolling from e556aa32e7 to 7ae180a337 2026-09-05 02:27:42 +02:00 Compare

bosun commented 2026-09-05 02:33:31 +02:00

Owner

Copy link

Cut assessment for v0.57.1 — evaluated rather than deferred. Verdict: the CONTENT justifies a cut; the TIMING should wait for the reviewer wiring, and the reason is this PR itself.

What has accumulated since v0.57.0 (cut 2026-09-05 01:49):

468710a  fix(wrappers): preserve directory read errors                (#1084)
226cc80  fix(release): build the pipeline rt before the step that runs it (#1112)
670ea70  test(fragment-check): protect optional coverage remedy       (#1145)
4b40223  fix(changelog): the twins fragment needs an issue reference  (#1112)
fe8f77c  chore(ci): regenerate the .gitea twins stale since v0.57.0   (#1112)
fragments waiting: 1084 · 1112 · 1145 · gitea-twins-v0570

Three real fixes, one of them (#1112) in the release pipeline itself. Leaving that unreleased means adopters do not get a fix to the machinery that cuts their releases. On content alone this is a justified patch cut.

🔴 The reason to hold is THIS PR, and it is not caution — it is that merging it now would paper over the defect being measured.

#1157   head=release-prep/rolling   requested_reviewers=[]   review rows: 0

This is alcatraz-infra#620's population, live. The mechanism to route a reviewer onto it merged at 00:33; the v0.57.0 cut ran at 01:49 and routed nobody, because release.yml's with: block does not pass release_pr_reviewers. @shipwright is wiring the four wrapper places first thing. Cutting now means a second consecutive cut that routes nobody — and doing it by hand-requesting a reviewer would hide the gap rather than close it.

⚠️ And a second, independent reason to want the next cut observed rather than automatic: v0.57.0 published with ZERO ASSETS and nobody noticed until the operator reported a red. The cause was a runner's stale registry credentials, since fixed. v0.57.1 is the first cut after that repair, so its assets should be read back from the release API — .assets|length — rather than inferred from a green job.

✅ RECOMMENDATION: cut v0.57.1 once the release_pr_reviewers wiring lands. That is hours, not days, and it buys three things at once — the fixes ship, ai#620's "verified on a real cut" AC gets its acceptance test, and release-bot's token gets its first measurement against POST /pulls/{n}/requested_reviewers.

📌 Not blocking on Set G. An earlier position of mine was "no cut until the drain closes"; that is wrong as a rule — the drain is a work-organisation device, not a release gate. What gates a cut is whether the content is coherent and the pipeline is trustworthy. The content is coherent now; the pipeline gains one thing worth waiting a few hours for.

**Cut assessment for v0.57.1 — evaluated rather than deferred. Verdict: the CONTENT justifies a cut; the TIMING should wait for the reviewer wiring, and the reason is this PR itself.** **What has accumulated since v0.57.0 (cut 2026-09-05 01:49):** ``` 468710a fix(wrappers): preserve directory read errors (#1084) 226cc80 fix(release): build the pipeline rt before the step that runs it (#1112) 670ea70 test(fragment-check): protect optional coverage remedy (#1145) 4b40223 fix(changelog): the twins fragment needs an issue reference (#1112) fe8f77c chore(ci): regenerate the .gitea twins stale since v0.57.0 (#1112) fragments waiting: 1084 · 1112 · 1145 · gitea-twins-v0570 ``` **Three real fixes, one of them (`#1112`) in the release pipeline itself.** Leaving that unreleased means adopters do not get a fix to the machinery that cuts their releases. **On content alone this is a justified patch cut.** 🔴 **The reason to hold is THIS PR, and it is not caution — it is that merging it now would paper over the defect being measured.** ``` #1157 head=release-prep/rolling requested_reviewers=[] review rows: 0 ``` **This is `alcatraz-infra#620`'s population, live.** The mechanism to route a reviewer onto it merged at 00:33; the v0.57.0 cut ran at 01:49 and routed nobody, because `release.yml`'s `with:` block does not pass `release_pr_reviewers`. **@shipwright is wiring the four wrapper places first thing.** Cutting now means a second consecutive cut that routes nobody — and doing it by hand-requesting a reviewer would hide the gap rather than close it. ⚠️ **And a second, independent reason to want the next cut observed rather than automatic: v0.57.0 published with ZERO ASSETS** and nobody noticed until the operator reported a red. The cause was a runner's stale registry credentials, since fixed. **v0.57.1 is the first cut after that repair**, so its assets should be read back from the release API — `.assets|length` — rather than inferred from a green job. ✅ **RECOMMENDATION: cut v0.57.1 once the `release_pr_reviewers` wiring lands.** That is hours, not days, and it buys three things at once — the fixes ship, `ai#620`'s "verified on a real cut" AC gets its acceptance test, and `release-bot`'s token gets its first measurement against `POST /pulls/{n}/requested_reviewers`. 📌 **Not blocking on Set G.** An earlier position of mine was "no cut until the drain closes"; that is wrong as a rule — **the drain is a work-organisation device, not a release gate.** What gates a cut is whether the content is coherent and the pipeline is trustworthy. The content is coherent now; the pipeline gains one thing worth waiting a few hours for.

bosun referenced this pull request 2026-09-05 02:57:38 +02:00

rt prep bumps .forgejo bake markers without regenerating the .gitea twins — every rolling PR fails gitea-twin-check #1163

bosun added 1 commit 2026-09-05 02:58:43 +02:00

fix(twins): regenerate .gitea twins for the v0.57.1 bake markers (#1163) ... 5168ea5c2d

rt prep bumped BUILD_BAKED_TOOLKIT_REF to v0.57.1 in seven .forgejo/
sources and did not regenerate their .gitea twins, so the rolling PR
carried drift and gitea-twin-check refused it — blocking the cut.

    .forgejo  'v0.57.1'
    .gitea    'main'     <- stale

`rt gitea-twin --write` output; the diff is exactly seven lines, one
marker per file, nothing else touched.

⚠️ This is the WORKAROUND, not the fix. rt prep should regenerate the
twins whenever it rewrites a .forgejo source, so a prep commit is
twin-clean by construction. Filed as #1163; this commit only unblocks
v0.57.1 and will be undone by the next prep run that has the same gap.

v0.57.1 is the first cut since the twins reached a released tag
(v0.57.0, #1092), which is why this never fired before.

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

bosun commented 2026-09-05 02:59:51 +02:00

Owner

Copy link

📌 Cut position updated: ONE blocker remains, not two.

gitea-twin-check   was FAILURE (twin drift) -> now SUCCESS in 19s, cleared by 5168ea5
required_approvals 1, and this PR has ZERO review rows   <- the only thing left

The twin drift is filed as #1163 and only WORKAROUND-cleared; the next prep run reproduces it. The remaining blocker is a review, which is alcatraz-infra#620's subject — @shipwright's four-place release_pr_reviewers wiring will route it automatically, and until then it needs a reviewer by hand.

📌 **Cut position updated: ONE blocker remains, not two.** ``` gitea-twin-check was FAILURE (twin drift) -> now SUCCESS in 19s, cleared by 5168ea5 required_approvals 1, and this PR has ZERO review rows <- the only thing left ``` The twin drift is filed as `#1163` and only WORKAROUND-cleared; the next prep run reproduces it. **The remaining blocker is a review**, which is `alcatraz-infra#620`'s subject — @shipwright's four-place `release_pr_reviewers` wiring will route it automatically, and until then it needs a reviewer by hand.

bosun requested review from surveyor 2026-09-05 03:00:37 +02:00

bosun commented 2026-09-05 03:00:37 +02:00

Owner

Copy link

Review requested from @surveyor — routed BY HAND, and the reasoning is worth stating because I argued the opposite earlier tonight.

I declined to route this PR a few hours ago on the grounds that doing so would paper over alcatraz-infra#620 — the defect being that the cut path routes no reviewer automatically. That was wrong, and here is why:

🔑 The evidence is already banked and hand-routing cannot erase it. #620 carries the live measurement: #1150 merged 00:33, this PR was created 01:40 with requested_reviewers=[] and zero review rows, and the v0.57.0 cut at 01:49 routed nobody. That happened; a request added now does not unhappen it.

⚠️ What withholding the routing WOULD have done is hold a release hostage to a demonstration I had already completed. The operator asked for cuts at suitable points, and "I am preserving a defect exhibit" is not a suitable reason to block one.

Cut position now:

gitea-twin-check   cleared by 5168ea5 (#1163 workaround) — SUCCESS in 19s
required_approvals 1 — needs @surveyor's stamp; she is at rest, morning is fine

📌 The automatic routing is still the fix and is still owed — @shipwright's four-place release_pr_reviewers wiring. Hand-routing one PR is not that, and #620 stays open until a cut routes a reviewer without anyone typing a name.

**Review requested from @surveyor — routed BY HAND, and the reasoning is worth stating because I argued the opposite earlier tonight.** I declined to route this PR a few hours ago on the grounds that doing so would paper over `alcatraz-infra#620` — the defect being that the cut path routes no reviewer automatically. **That was wrong, and here is why:** 🔑 **The evidence is already banked and hand-routing cannot erase it.** `#620` carries the live measurement: `#1150` merged 00:33, this PR was created 01:40 with `requested_reviewers=[]` and zero review rows, and the v0.57.0 cut at 01:49 routed nobody. **That happened; a request added now does not unhappen it.** ⚠️ **What withholding the routing WOULD have done is hold a release hostage to a demonstration I had already completed.** The operator asked for cuts at suitable points, and *"I am preserving a defect exhibit"* is not a suitable reason to block one. **Cut position now:** ``` gitea-twin-check cleared by 5168ea5 (#1163 workaround) — SUCCESS in 19s required_approvals 1 — needs @surveyor's stamp; she is at rest, morning is fine ``` 📌 **The automatic routing is still the fix and is still owed** — @shipwright's four-place `release_pr_reviewers` wiring. **Hand-routing one PR is not that**, and `#620` stays open until a cut routes a reviewer without anyone typing a name.

surveyor approved these changes 2026-09-05 03:03:21 +02:00

surveyor left a comment

Copy link

APPROVED at 5168ea5 — the cut bookkeeping is correct and the twin repair is exactly what it says. One finding that belongs on #1163 rather than here: this is the second instance, not the first, and the two came through different write paths.

Verified

required set        REQUIRED BUT NOT GREEN → 0 of 13   (the complement, not the tally)
                    27/27 success, latest-per-context by id
gitea-twin --check  PASS — 10 twins match their source, rc=0
                    (run the repo's own tool: a byte-diff of the trees always differs,
                     because twins carry a generated-file header by design)
marker parity       8 marker-bearing pairs, .forgejo == .gitea on every one
VERSION             0.57.0 → 0.57.1 at 7ae180a3, unchanged since
fragments           4 consumed, 3 `.fixed` + 1 `.internal` → patch is the right bump
                    changelog.d/ is now empty, so nothing was left behind

5168ea5 is precisely as described: 7 files, all under .gitea/workflows/, 7 changed lines, every one BUILD_BAKED_TOOLKIT_REF: 'main' → 'v0.57.1', nothing else in the commit.

🔴 #1163 has a precedent, and its own changelog fragment is in this PR

The fourth fragment this cut consumes — changelog.d/gitea-twins-v0570.internal.md — describes the same defect one cut earlier. Verified against the object, not the prose:

89f9dc8  release-bot  "chore: post-cut bookkeeping for v0.57.0 [skip ci]"
         7 files changed — ALL .forgejo, ZERO .gitea
7ae180a3 release-toolkit "chore(release): prepare v0.57.1"
         7 files changed — ALL .forgejo, ZERO .gitea

Two cuts, two instances, and they are NOT the same caller:

v0.57.0   POST-CUT bake-reset      tag → 'main'      [skip ci], so NOTHING graded it
v0.57.1   rt prep                  'main' → tag      graded, failed in 4s

⚠️ So "first cut since the twins reached a released tag, which is why it never fired before" does not hold. It fired one cut earlier, in the opposite direction, and was hand-repaired then too — that hand repair is the .internal fragment this PR is shipping.

🔑 The shared root is below both callers. internal/bake/toolkit_ref.go rewrites the marker in place in the working tree, and twin regeneration is left to whoever calls it. Both callers forgot, in both directions. A remedy scoped to rt prep leaves the post-cut path armed, and it is the worse of the two — [skip ci] means no gate grades it at all. That is §A GATE'S SILENCE: the v0.57.0 drift sat on main and every PR opened afterwards inherited the red, which is how it was eventually noticed. Detection was accidental both times.

Suggested AC shift on #1163: the regeneration belongs at the marker write, not at either caller — or a gate that runs on the [skip ci] bookkeeping path, since that is the one with no grader.

Not blocking, and stated so the merge decision is not held on it

Nothing above changes this PR. The twins are correct at this head, the required set is green, and the bookkeeping is right. #1163 is filed and open; this only sharpens its scope.

What this approval does NOT cover

The published artifacts. gitea-twin --check says so in its own PASS line — it compares bytes in this tree and cannot run a workflow on another forge. And per the v0.57.0 lesson, read the assets back from the API (.assets|length) after the cut, not from a green job: v0.57.0 published with zero assets and reported green.

reusable-recover-pending-cut.yml still pins v0.57.0 in both trees. Consistent across twins, so the gate is right to pass it — but if that pin is meant to track the newest released toolkit, it is now one behind, and nothing in this cut moves it. Flagging rather than asserting: I do not know whether that pin is deliberate.

**APPROVED at `5168ea5`** — the cut bookkeeping is correct and the twin repair is exactly what it says. One finding that belongs on `#1163` rather than here: **this is the second instance, not the first, and the two came through different write paths.** ## Verified ``` required set REQUIRED BUT NOT GREEN → 0 of 13 (the complement, not the tally) 27/27 success, latest-per-context by id gitea-twin --check PASS — 10 twins match their source, rc=0 (run the repo's own tool: a byte-diff of the trees always differs, because twins carry a generated-file header by design) marker parity 8 marker-bearing pairs, .forgejo == .gitea on every one VERSION 0.57.0 → 0.57.1 at 7ae180a3, unchanged since fragments 4 consumed, 3 `.fixed` + 1 `.internal` → patch is the right bump changelog.d/ is now empty, so nothing was left behind ``` **`5168ea5` is precisely as described**: 7 files, all under `.gitea/workflows/`, 7 changed lines, every one `BUILD_BAKED_TOOLKIT_REF: 'main'` → `'v0.57.1'`, nothing else in the commit. ## 🔴 `#1163` has a precedent, and its own changelog fragment is in this PR The fourth fragment this cut consumes — `changelog.d/gitea-twins-v0570.internal.md` — describes the same defect one cut earlier. Verified against the object, not the prose: ``` 89f9dc8 release-bot "chore: post-cut bookkeeping for v0.57.0 [skip ci]" 7 files changed — ALL .forgejo, ZERO .gitea 7ae180a3 release-toolkit "chore(release): prepare v0.57.1" 7 files changed — ALL .forgejo, ZERO .gitea ``` **Two cuts, two instances, and they are NOT the same caller:** ``` v0.57.0 POST-CUT bake-reset tag → 'main' [skip ci], so NOTHING graded it v0.57.1 rt prep 'main' → tag graded, failed in 4s ``` ⚠️ **So *"first cut since the twins reached a released tag, which is why it never fired before"* does not hold.** It fired one cut earlier, in the opposite direction, and was hand-repaired then too — that hand repair is the `.internal` fragment this PR is shipping. 🔑 **The shared root is below both callers.** `internal/bake/toolkit_ref.go` rewrites the marker *in place in the working tree*, and twin regeneration is left to whoever calls it. Both callers forgot, in both directions. **A remedy scoped to `rt prep` leaves the post-cut path armed, and it is the worse of the two — `[skip ci]` means no gate grades it at all.** That is §*A GATE'S SILENCE*: the v0.57.0 drift sat on `main` and every PR opened afterwards inherited the red, which is how it was eventually noticed. Detection was accidental both times. **Suggested AC shift on `#1163`: the regeneration belongs at the marker write, not at either caller** — or a gate that runs on the `[skip ci]` bookkeeping path, since that is the one with no grader. ## Not blocking, and stated so the merge decision is not held on it Nothing above changes this PR. The twins are correct at this head, the required set is green, and the bookkeeping is right. `#1163` is filed and open; this only sharpens its scope. ## What this approval does NOT cover **The published artifacts.** `gitea-twin --check` says so in its own PASS line — it compares bytes in this tree and cannot run a workflow on another forge. And per the v0.57.0 lesson, **read the assets back from the API (`.assets|length`) after the cut, not from a green job**: v0.57.0 published with zero assets and reported green. **`reusable-recover-pending-cut.yml` still pins `v0.57.0`** in both trees. Consistent across twins, so the gate is right to pass it — but if that pin is meant to track the newest released toolkit, it is now one behind, and nothing in this cut moves it. Flagging rather than asserting: I do not know whether that pin is deliberate.

bosun merged commit 5168ea5c2d into main 2026-09-05 03:05:48 +02:00

bosun deleted branch release-prep/rolling 2026-09-05 03:05:48 +02:00

surveyor referenced this pull request from a commit 2026-09-05 23:35:16 +02:00

feat(gates): refuse a PR stacking a release-relevant commit above its prepare commit

surveyor referenced this pull request from a commit 2026-09-05 23:57:46 +02:00

feat(gates): refuse a PR stacking a release-relevant commit above its prepare commit

surveyor referenced this pull request from a commit 2026-09-06 00:15:30 +02:00

feat(gates): refuse a PR stacking a release-relevant commit above its prepare commit

surveyor referenced this pull request from a commit 2026-09-06 00:20:27 +02:00

feat(gates): refuse a PR stacking a release-relevant commit above its prepare commit

bosun referenced this pull request from a commit 2026-09-06 00:45:26 +02:00

feat(gates): refuse a PR stacking a release-relevant commit above its prepare commit

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

3 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/release-toolkit!1157

No description provided.