chore(release): v0.63.0 #1448

Merged

bosun merged 1 commit from release-prep/rolling into main 2026-09-07 23:42:49 +02:00

Conversation 2 Commits 1 Files changed 37 +63 -121

release-bot commented 2026-09-07 20:43:10 +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

• adoption: mirror-release.yml gains a guarded force_recreate (#1426).

Changed

None.

Fixed

• adoption: a corrected release note now reaches the public mirror (#1426).
• release-state: v0.62.4 is recorded in the manifest, so the release gate stops refusing every push (#1444).
• prepared-uncut-check: published interrupted cuts now name manifest-only recovery and correct SHA/time semantics (#1452).
• fragment-check: local runs now refuse with COULD-NOT-GRADE when PR coverage inputs are absent (#1456).
• decide: the pending-cut message no longer recommends a destructive recovery on a shipped release (#1457)
• release gate: digest-pin-verify distinguishes stale anchors from wrong tags (#1458)

Removed

None.

Deprecated

None.

Upgrade

None.

Internal

• ci: the drift report now reopens its tracker before commenting (#1348)
• docs: the integration guide's adoption path carries no historical asides (#1407)
• fix: the worked-example provenance check no longer reports a documented section as undocumented (#1421)
• internal: the Status rule says which numbers it is about (#1423).
• docs: six passages no longer assume the reader knows our internal vocabulary (#1427)
• test: the cut path's doc-staging step is now covered (#1438)
• ci: mirror-drift-check now grades the newest release instead of excluding it permanently (#1445)
• internal: manifest pushes retry on concurrent base advances; fail closed on unchanged, non-linear, unrelated, conflicting, or repeated rejection (#1447).
• internal: anchor-check now runs in the pull-request docs gate and preserves could-not-grade diagnostics (#1451).
• internal: pull-request docs checks now reject tags whose action image digest is still the all-zero placeholder (#1453).

<!-- 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 - **adoption**: `mirror-release.yml` gains a guarded `force_recreate` (#1426). ### Changed None. ### Fixed - **adoption**: a corrected release note now reaches the public mirror (#1426). - **release-state**: v0.62.4 is recorded in the manifest, so the release gate stops refusing every push (#1444). - **prepared-uncut-check**: published interrupted cuts now name manifest-only recovery and correct SHA/time semantics (#1452). - **fragment-check**: local runs now refuse with COULD-NOT-GRADE when PR coverage inputs are absent (#1456). - **decide**: the pending-cut message no longer recommends a destructive recovery on a shipped release (#1457) - **release gate**: `digest-pin-verify` distinguishes stale anchors from wrong tags (#1458) ### Removed None. ### Deprecated None. ### Upgrade None. ### Internal - **ci**: the drift report now reopens its tracker before commenting (#1348) - **docs**: the integration guide's adoption path carries no historical asides (#1407) - **fix**: the worked-example provenance check no longer reports a documented section as undocumented (#1421) - **internal**: the Status rule says which numbers it is about (#1423). - **docs**: six passages no longer assume the reader knows our internal vocabulary (#1427) - **test**: the cut path's doc-staging step is now covered (#1438) - **ci**: `mirror-drift-check` now grades the newest release instead of excluding it permanently (#1445) - **internal**: manifest pushes retry on concurrent base advances; fail closed on unchanged, non-linear, unrelated, conflicting, or repeated rejection (#1447). - **internal**: anchor-check now runs in the pull-request docs gate and preserves could-not-grade diagnostics (#1451). - **internal**: pull-request docs checks now reject tags whose action image digest is still the all-zero placeholder (#1453).

release-bot added 1 commit 2026-09-07 20:43:10 +02:00

chore(release): prepare v0.63.0 ... ec96f54870

Generated by release-toolkit rt prep.

Tracker: frankenbit/release-toolkit#1

release-bot requested review from surveyor 2026-09-07 20:43:11 +02:00

release-bot force-pushed release-prep/rolling from ec96f54870 to c63143695a 2026-09-07 20:56:37 +02:00 Compare

release-bot force-pushed release-prep/rolling from c63143695a to a768bd2096 2026-09-07 21:19:51 +02:00 Compare

release-bot force-pushed release-prep/rolling from a768bd2096 to 70964794fd 2026-09-07 21:24:11 +02:00 Compare

release-bot force-pushed release-prep/rolling from 70964794fd to e1f4d3d49d 2026-09-07 21:48:03 +02:00 Compare

release-bot force-pushed release-prep/rolling from e1f4d3d49d to d1458fd213 2026-09-07 21:52:38 +02:00 Compare

release-bot force-pushed release-prep/rolling from d1458fd213 to 8ec5220611 2026-09-07 22:19:06 +02:00 Compare

release-bot force-pushed release-prep/rolling from 8ec5220611 to 0ab48d11b6 2026-09-07 22:24:30 +02:00 Compare

release-bot force-pushed release-prep/rolling from 0ab48d11b6 to 4bea5600a3 2026-09-07 22:28:36 +02:00 Compare

surveyor approved these changes 2026-09-07 23:40:41 +02:00

surveyor left a comment

Copy link

APPROVED @ 4bea5600. The artifact is clean. There is one live red, it is real, it is not caused by this PR, and it cannot block — so my stamp is the only enforcement and I am saying explicitly why I am not using it to hold.

The artifact — graded, not skimmed

VERSION                0.62.4 -> 0.63.0
fragments consumed     17 deleted
CHANGELOG bullets      17 added; 16 distinct refs (#1426 appears in Added AND Fixed)
set difference         fragments \ changelog = EMPTY ; changelog \ fragments = EMPTY
                       (both sides non-empty: 16 and 16 — the control)
build-ref pins         18 files, EXACTLY one distinct - line and one distinct + line:
                       'v0.62.4' -> 'v0.63.0'
files                  37 of 37 (paginated; changed_files is the denominator)
required contexts      complement = 0 of 23, enable_status_check=true
approvals whitelist    team `crew`, and surveyor is in it — so this stamp counts

🔴 The red: readme-pin-check / check — reproduced locally, and it is the SECOND step

Not in status_check_contexts, so nothing holds the merge on it. I built rt from this head and ran the gate's exact argv:

readme-pin-check          rc=0   18 prescriptive pins across 11 documents, all @v0.62.4, all servable
tag-action-digest-check   rc=1   tag v0.62.4 carries the all-zero image-digest placeholder in action.yml

The docs pin exactly one version — @v0.62.4, 18 times — and that tag's action is unusable. An adopter following docs/integration.md today gets sha256:000…0.

⚠️ I nearly reported a mechanism that does not exist, and the correction is the useful part

My first pass read action.yml at each tag from a local clone and produced this:

v0.62.4 ZERO · v0.62.3 real · v0.62.2 real · v0.62.1 ZERO · v0.62.0 real
v0.61.1 ZERO · v0.61.0 ZERO · v0.60.0 ZERO

I was one paragraph from writing "the bake is intermittent — 3 of the last 5 succeeded, so a spot-check would have said it works." It is not intermittent. Three of those eight reads were STALE: git fetch --tags does not move a tag ref that already exists locally, and the bake step force-moves the tag after committing the digest. After git fetch --force --tags, v0.62.1, v0.61.0 and v0.60.0 all moved and all carry real digests — confirmed against the API, which never touched my clone.

v0.62.4  ALL-ZERO   goreleaser run 25965  FAILURE
v0.62.3  real                             success
v0.62.2  real                             success
v0.62.1  real                             success     <- I had this ZERO
v0.62.0  real                             success
v0.61.1  ALL-ZERO   goreleaser run 22680  FAILURE
v0.61.0  real                             success     <- I had this ZERO
v0.60.0  real                             success     <- I had this ZERO

Corrected, it is perfectly deterministic: exactly the two tags whose goreleaser run FAILED carry the placeholder, and every successful run baked a real digest. The mechanism is the job order — goreleaser publishes the release, publish-image bakes and force-moves the tag afterwards — so a failure anywhere downstream of publication leaves a published release whose tag never got its digest. Fail-closed protects the tag from a WRONG pin; it cannot un-publish the release.

📌 readme-pin-check.yml's own step does git fetch --force --tags and its comment explains only the MISSING-tag case ("A missing local tag is COULD-NOT-GRADE"). The --force is load-bearing for a second reason the comment does not name: a stale tag is not missing, it answers confidently, and it answers wrong. Worth one line in that comment — it is the failure I actually hit.

The number in #1453's title

Its title says "five tags pin an all-zeros image digest". Swept all 122 tags after the force-fetch:

122 tags · 40 carry a sha256 pin · 14 ALL-ZERO · 82 no action.yml or no pin
all-zero: v0.43.0 v0.44.0 v0.44.1 v0.44.2 v0.45.0 v0.45.1 v0.46.0 v0.46.1
          v0.47.0 v0.48.0 v0.50.0 v0.54.1 v0.61.1 v0.62.4
DOC-PINNED among them: v0.62.4, and only v0.62.4 — the docs pin one version.

Three different true numbers — 14 tag-wide, 2 in the last eight, 1 doc-pinned — and they answer three different questions. The one that describes adopter exposure is 1. I am not asking anyone to renumber the title; I am recording the scope beside each figure so the next reader does not reconcile them.

✅ Why I am not holding on it

Merging cuts v0.63.0 and does not touch the doc pins — prep does not advance them; mirror-release.yml does, after a manual mirror publish. So at merge time the docs still say @v0.62.4 whatever happens.

cut succeeds   v0.63.0 gets a real digest.   Docs still @v0.62.4. Red unchanged.
cut fails      v0.63.0 joins the broken set. Docs still @v0.62.4. No NEW exposure.

Holding this PR does not repair v0.62.4 and does not protect anyone from it. It would block the release train to protest a defect in an already-published release — a delay that fixes nothing, which is the false-hold shape this file warns costs nothing visible and wears the clothing of caution.

🔴 The one thing that IS actionable, and it is an ORDERING

The path that advances the doc pins does not run the digest check.

mirror-release.yml           tag-action-digest hits: 0   <- this is what re-pins the docs
reusable-mirror-release.yml  tag-action-digest hits: 0
readme-pin-check.yml         tag-action-digest hits: 5   <- runs only on pull_request

mirror-release.yml's "point the README at what the mirror can now serve" job runs rt readme-pin-check --fix — mirror servability — and nothing grades the tag's action digest before the pin moves. That is how @v0.62.4 became the pinned version while carrying the placeholder, and the detector that would have caught it (#1453/#1462) landed in this release cycle, after the fact.

✅ The ask, and it is not this PR's job to carry it: do not advance the doc pins to v0.63.0 until tag-action-digest-check passes on v0.63.0. Either add the digest check to the --fix job before it opens the pin PR, or add readme-pin-check / check to status_check_contexts so the pin PR cannot merge red. Today the only thing standing between a broken tag and the docs is a red on an advisory context.

¶41 — you asked me to read the composed sequence, and the trigger does not fire

#1447 (rt post-cut's manifest push, inside reusable-release.yml's cut path) and #1449 (mirror-drift-check.yml, on: release: [published]).

The trigger is both touch one ordered construct AND at least one MOVES state the other READS. The second half is false here: mirror-drift-check.yml contains zero references to manifest or last_released_sha — it reads gitea.com's mirror state, not the manifest post-cut writes. They are independent, not composed.

📌 And the ordering hazard that DOES live in that pair was already found and handled — #1445's header: the release-event run cannot grade its own tag, EXCLUDE_TAG is set for the whole run, so the newest release had no drift signal until the next cut. The daily cron with an empty EXCLUDE_TAG is the fix, and the newest-release pending context makes the gap visible immediately. I checked for your hazard and found their remedy for a different one.

What I did NOT check

The .gitea twins are not byte-identical to their .forgejo counterparts (11 of them). I did not grade that and I am not reporting it: gitea-twin-check / check is required and green, and it is the gate that owns the invariant — a hand-rolled cmp here would be a first opinion with a false witness. I also did not re-verify the 17 fragments' individual prose; fragment-check and changelog-body-check are both required and both green.

---

⚠️ This is the ROLLING PR — the release bot force-pushes it on every base move, and dismiss_stale_approvals=true. This stamp is bound to 4bea5600 and expires the moment the base moves. Re-ping me if it does; do not merge on a dismissed row.

**APPROVED @ `4bea5600`.** The artifact is clean. There is one live red, it is real, it is not caused by this PR, and it cannot block — so my stamp is the only enforcement and I am saying explicitly why I am not using it to hold. ## The artifact — graded, not skimmed ``` VERSION 0.62.4 -> 0.63.0 fragments consumed 17 deleted CHANGELOG bullets 17 added; 16 distinct refs (#1426 appears in Added AND Fixed) set difference fragments \ changelog = EMPTY ; changelog \ fragments = EMPTY (both sides non-empty: 16 and 16 — the control) build-ref pins 18 files, EXACTLY one distinct - line and one distinct + line: 'v0.62.4' -> 'v0.63.0' files 37 of 37 (paginated; changed_files is the denominator) required contexts complement = 0 of 23, enable_status_check=true approvals whitelist team `crew`, and surveyor is in it — so this stamp counts ``` ## 🔴 The red: `readme-pin-check / check` — reproduced locally, and it is the SECOND step Not in `status_check_contexts`, so nothing holds the merge on it. I built `rt` from this head and ran the gate's exact argv: ``` readme-pin-check rc=0 18 prescriptive pins across 11 documents, all @v0.62.4, all servable tag-action-digest-check rc=1 tag v0.62.4 carries the all-zero image-digest placeholder in action.yml ``` **The docs pin exactly one version — `@v0.62.4`, 18 times — and that tag's action is unusable.** An adopter following `docs/integration.md` today gets `sha256:000…0`. ### ⚠️ I nearly reported a mechanism that does not exist, and the correction is the useful part My first pass read `action.yml` at each tag from a local clone and produced this: ``` v0.62.4 ZERO · v0.62.3 real · v0.62.2 real · v0.62.1 ZERO · v0.62.0 real v0.61.1 ZERO · v0.61.0 ZERO · v0.60.0 ZERO ``` I was one paragraph from writing *"the bake is intermittent — 3 of the last 5 succeeded, so a spot-check would have said it works."* **It is not intermittent. Three of those eight reads were STALE**: `git fetch --tags` does **not** move a tag ref that already exists locally, and the bake step force-moves the tag after committing the digest. After `git fetch --force --tags`, `v0.62.1`, `v0.61.0` and `v0.60.0` all moved and all carry real digests — confirmed against the API, which never touched my clone. ``` v0.62.4 ALL-ZERO goreleaser run 25965 FAILURE v0.62.3 real success v0.62.2 real success v0.62.1 real success <- I had this ZERO v0.62.0 real success v0.61.1 ALL-ZERO goreleaser run 22680 FAILURE v0.61.0 real success <- I had this ZERO v0.60.0 real success <- I had this ZERO ``` **Corrected, it is perfectly deterministic: exactly the two tags whose goreleaser run FAILED carry the placeholder, and every successful run baked a real digest.** The mechanism is the job order — `goreleaser` publishes the release, `publish-image` bakes and force-moves the tag afterwards — so a failure anywhere downstream of publication leaves a *published* release whose tag never got its digest. Fail-closed protects the tag from a WRONG pin; it cannot un-publish the release. 📌 **`readme-pin-check.yml`'s own step does `git fetch --force --tags` and its comment explains only the MISSING-tag case** (*"A missing local tag is COULD-NOT-GRADE"*). **The `--force` is load-bearing for a second reason the comment does not name: a stale tag is not missing, it answers confidently, and it answers wrong.** Worth one line in that comment — it is the failure I actually hit. ### The number in `#1453`'s title Its title says *"five tags pin an all-zeros image digest"*. Swept all 122 tags after the force-fetch: ``` 122 tags · 40 carry a sha256 pin · 14 ALL-ZERO · 82 no action.yml or no pin all-zero: v0.43.0 v0.44.0 v0.44.1 v0.44.2 v0.45.0 v0.45.1 v0.46.0 v0.46.1 v0.47.0 v0.48.0 v0.50.0 v0.54.1 v0.61.1 v0.62.4 DOC-PINNED among them: v0.62.4, and only v0.62.4 — the docs pin one version. ``` **Three different true numbers — 14 tag-wide, 2 in the last eight, 1 doc-pinned — and they answer three different questions.** The one that describes adopter exposure is `1`. I am not asking anyone to renumber the title; I am recording the scope beside each figure so the next reader does not reconcile them. ## ✅ Why I am not holding on it **Merging cuts `v0.63.0` and does not touch the doc pins** — `prep` does not advance them; `mirror-release.yml` does, after a manual mirror publish. So at merge time the docs still say `@v0.62.4` whatever happens. ``` cut succeeds v0.63.0 gets a real digest. Docs still @v0.62.4. Red unchanged. cut fails v0.63.0 joins the broken set. Docs still @v0.62.4. No NEW exposure. ``` **Holding this PR does not repair `v0.62.4` and does not protect anyone from it.** It would block the release train to protest a defect in an already-published release — a delay that fixes nothing, which is the false-hold shape this file warns costs nothing visible and wears the clothing of caution. ## 🔴 The one thing that IS actionable, and it is an ORDERING **The path that advances the doc pins does not run the digest check.** ``` mirror-release.yml tag-action-digest hits: 0 <- this is what re-pins the docs reusable-mirror-release.yml tag-action-digest hits: 0 readme-pin-check.yml tag-action-digest hits: 5 <- runs only on pull_request ``` `mirror-release.yml`'s *"point the README at what the mirror can now serve"* job runs `rt readme-pin-check --fix` — mirror servability — and nothing grades the tag's action digest before the pin moves. **That is how `@v0.62.4` became the pinned version while carrying the placeholder**, and the detector that would have caught it (`#1453`/`#1462`) landed in *this* release cycle, after the fact. ✅ **The ask, and it is not this PR's job to carry it: do not advance the doc pins to `v0.63.0` until `tag-action-digest-check` passes on `v0.63.0`.** Either add the digest check to the `--fix` job before it opens the pin PR, or add `readme-pin-check / check` to `status_check_contexts` so the pin PR cannot merge red. **Today the only thing standing between a broken tag and the docs is a red on an advisory context.** ## ¶41 — you asked me to read the composed sequence, and the trigger does not fire `#1447` (`rt post-cut`'s manifest push, inside `reusable-release.yml`'s cut path) and `#1449` (`mirror-drift-check.yml`, `on: release: [published]`). **The trigger is *both touch one ordered construct AND at least one MOVES state the other READS*. The second half is false here:** `mirror-drift-check.yml` contains zero references to `manifest` or `last_released_sha` — it reads `gitea.com`'s mirror state, not the manifest `post-cut` writes. They are independent, not composed. 📌 **And the ordering hazard that DOES live in that pair was already found and handled** — `#1445`'s header: the release-event run cannot grade its own tag, `EXCLUDE_TAG` is set for the whole run, so the newest release had no drift signal until the next cut. The daily cron with an empty `EXCLUDE_TAG` is the fix, and the `newest-release` pending context makes the gap visible immediately. **I checked for your hazard and found their remedy for a different one.** ## What I did NOT check The `.gitea` twins are not byte-identical to their `.forgejo` counterparts (11 of them). **I did not grade that and I am not reporting it**: `gitea-twin-check / check` is required and green, and it is the gate that owns the invariant — a hand-rolled `cmp` here would be a first opinion with a false witness. I also did not re-verify the 17 fragments' individual prose; `fragment-check` and `changelog-body-check` are both required and both green. --- ⚠️ **This is the ROLLING PR — the release bot force-pushes it on every base move, and `dismiss_stale_approvals=true`.** This stamp is bound to `4bea5600` and expires the moment the base moves. **Re-ping me if it does; do not merge on a dismissed row.**

bosun merged commit 4bea5600a3 into main 2026-09-07 23:42:49 +02:00

forgejo-actions commented 2026-09-07 23:43:00 +02:00

Copy link

Landing identity record

• PR: #1448
• landed commit (server merge_commit_sha): 4bea5600a3e1d5812900e051fd050c5bb246792f
• effective official approval(s):
  • @surveyor, review #7052, stamped commit: 4bea5600a3e1d5812900e051fd050c5bb246792f
• replay comparison: no identity change (stamped SHA equals landed SHA)

This is a post-merge identity record. It does not retroactively review the landed object; it records whether the server landed the object that an official approval named.

<!-- release-toolkit:landing-review-record-v1 landed=4bea5600a3e1d5812900e051fd050c5bb246792f --> ## Landing identity record - PR: #1448 - landed commit (server merge_commit_sha): `4bea5600a3e1d5812900e051fd050c5bb246792f` - effective official approval(s): - @surveyor, review #7052, stamped commit: `4bea5600a3e1d5812900e051fd050c5bb246792f` - replay comparison: no identity change (stamped SHA equals landed SHA) This is a post-merge identity record. It does not retroactively review the landed object; it records whether the server landed the object that an official approval named.

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!1448

No description provided.