chore(release): v0.63.1 #1468

Merged

bosun merged 1 commit from release-prep/rolling into main 2026-09-08 01:19:21 +02:00

Conversation 2 Commits 1 Files changed 23 +47 -22

release-bot commented 2026-09-08 00:34:18 +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

• readme-pin-check: splits mirror availability from digest grading; rejects placeholder image digests before opening adopter pin PRs (#1463).
• fragment-check: coverage and density now post as separate named contexts (#1465).
• record-landing-review: rejects repeated review/comment pages before runner timeout (#1469).

Removed

None.

Deprecated

None.

Upgrade

None.

<!-- 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 - **readme-pin-check**: splits mirror availability from digest grading; rejects placeholder image digests before opening adopter pin PRs (#1463). - **fragment-check**: coverage and density now post as separate named contexts (#1465). - **record-landing-review**: rejects repeated review/comment pages before runner timeout (#1469). ### Removed None. ### Deprecated None. ### Upgrade None.

release-bot added 1 commit 2026-09-08 00:34:18 +02:00

chore(release): prepare v0.63.1 ... 0a19920cc4

Generated by release-toolkit rt prep.

Tracker: frankenbit/release-toolkit#1

release-bot requested review from surveyor 2026-09-08 00:34:19 +02:00

release-bot force-pushed release-prep/rolling from 0a19920cc4 to e6d69f04b7 2026-09-08 00:54:29 +02:00 Compare

release-bot force-pushed release-prep/rolling from e6d69f04b7 to d2749e2458 2026-09-08 01:15:40 +02:00 Compare

surveyor approved these changes 2026-09-08 01:18:27 +02:00

surveyor left a comment

Copy link

APPROVED @ d2749e24. My first submit was refused by the head-pin gate — the branch rebased onto c5142ab1 after #1469 landed while I was reviewing. Re-graded on the new head and base.

Artifact

VERSION                0.63.0 -> 0.63.1
fragments consumed     3  (#1463 #1465 #1469)
CHANGELOG bullets      3, distinct refs 3
set difference         EMPTY both ways, both sides non-empty (the control)
build-ref pins         18 files, exactly one distinct - line and one + line: 'main' -> 'v0.63.1'
files                  23 of 23 (paginated)
complement             0 of 25 required; zero non-success rows

📌 The context string I flagged is correct. readme-pin-check / digest (pull_request) is in status_check_contexts, and 25 of 25 required contexts carry the suffix. That was the way the follow-up could have gone quietly wrong, and it did not.

⚠️ A cancelled run posts failure, and I nearly filed that as a finding

My first sweep of this head showed two REQUIRED contexts red — fragment-check / check and toolkit-self-gates — and the obvious story was "the rebase onto #1469 broke two gates." It broke nothing:

56  fragment-check / check   failure   "Has been cancelled"     <- what I caught
84  fragment-check / check   pending   "Blocked by required conditions"
86  fragment-check / check   success   "Successful in 0s"

The push cancelled the in-flight run for the previous head, and a cancelled job posts failure. My sweep took the newest row at a moment when the cancellation was newest.

🔑 This is the same shape as #1466's skipped job, running the other way, and the pair is worth holding together:

skipped   -> status success   ("Has been skipped")     a gate that never ran reads GREEN
cancelled -> status failure   ("Has been cancelled")   a gate that never ran reads RED

On this forge the status value does not distinguish ran from did not run, in either direction. The description field does. ✅ Read the description alongside the status, and never grade a head while its run is in flight — the load-bearing discipline is waiting for pending == 0 before believing any row, which is what this stamp is bound to.

The v0.62.4 cut has a second symptom, and it was in #1448's own diff

The pins here move 'main' -> 'v0.63.1'. On #1448 they moved 'v0.62.4' -> 'v0.63.0'. That difference is the finding:

494c7785  post-cut bookkeeping for v0.62.2   pin -> 'main'
d4917b72  prepare v0.62.3                    pin -> 'v0.62.3'
24491072  post-cut bookkeeping for v0.62.3   pin -> 'main'
e45075a1  prepare v0.62.4                    pin -> 'v0.62.4'
          — no post-cut bookkeeping for v0.62.4 exists —
4bea5600  prepare v0.63.0                    pin -> 'v0.63.0'
454d8095  post-cut bookkeeping for v0.63.0   pin -> 'main'

prep bakes the tag, post-cut resets to main; main -> v0.63.1 is the healthy cycle. The v0.62.4 row is broken because its post-cut bookkeeping never ran at all — the same goreleaser failure (run 25965) that left the all-zero action digest, seen in the manifest path rather than the image path.

🔑 Two independent symptoms of one failed cut, and the second was sitting in #1448's diff as a base pin reading v0.62.4 where every healthy prep reads main. Nobody looked at it, including me.

⚠️ The new required context: two placements, one grader — and one state it cannot exit

mirror-release.yml      rt tag-action-digest-check   before the pin PR opens
readme-pin-check.yml    rt tag-action-digest-check   on the pin PR, now REQUIRED

Same verb. That is ordering, not independence — a blind spot in the verb is a blind spot in both. The placements still buy something real: the first prevents the PR existing, the second catches a pin PR opened by hand.

🔴 The required context grades whatever the DOCS pin, not this PR's content. So if the docs ever pin a tag with a placeholder digest, every PR to main goes red, including the PR that would fix the docs.

today          docs pin v0.63.0, real digest, green, no exposure
entry          only by advancing the docs to a broken tag — set-adopter-pin closes
               the automatic path; a hand edit of the pin does not
recovery       admin removes the context, or force-merges the fix. No in-band path,
               because the fix is itself a PR.

Not a reason to hold and not an argument against requiring it — requiring it is exactly what #1448 asked for. It is a reason to know the recovery before it is needed, and to prefer a --fix PR over a hand edit of the pin, always.

What v0.63.1 actually tests, and a cheap check after the cut

The live run of the new gate is not this PR — it is the pin PR that follows the mirror publish. If v0.63.1's bake fails the way v0.62.4's did, set-adopter-pin refuses before a pin PR opens and the docs stay on v0.63.0, which has a real digest.

📌 After the cut, two commands, and they are independent of each other:

git fetch --force --tags   then read action.yml at v0.63.1   -> non-placeholder digest?
git log --grep='post-cut bookkeeping for v0.63.1'            -> does the commit exist?

Those are the two symptoms of the v0.62.4 failure. Checking one and not the other is how the second one stayed invisible for a day.

---

Bound to d2749e24, base c5142ab1. Rolling PR: the bot force-pushes on every base move and dismiss_stale_approvals clears this stamp when it does — it already happened once during this review. Re-ping rather than merging on a dismissed row.

**APPROVED @ `d2749e24`.** My first submit was refused by the head-pin gate — the branch rebased onto `c5142ab1` after `#1469` landed while I was reviewing. Re-graded on the new head and base. ## Artifact ``` VERSION 0.63.0 -> 0.63.1 fragments consumed 3 (#1463 #1465 #1469) CHANGELOG bullets 3, distinct refs 3 set difference EMPTY both ways, both sides non-empty (the control) build-ref pins 18 files, exactly one distinct - line and one + line: 'main' -> 'v0.63.1' files 23 of 23 (paginated) complement 0 of 25 required; zero non-success rows ``` 📌 **The context string I flagged is correct.** `readme-pin-check / digest (pull_request)` is in `status_check_contexts`, and **25 of 25 required contexts carry the suffix**. That was the way the follow-up could have gone quietly wrong, and it did not. ## ⚠️ A cancelled run posts `failure`, and I nearly filed that as a finding My first sweep of this head showed two REQUIRED contexts red — `fragment-check / check` and `toolkit-self-gates` — and the obvious story was *"the rebase onto `#1469` broke two gates."* It broke nothing: ``` 56 fragment-check / check failure "Has been cancelled" <- what I caught 84 fragment-check / check pending "Blocked by required conditions" 86 fragment-check / check success "Successful in 0s" ``` **The push cancelled the in-flight run for the previous head, and a cancelled job posts `failure`.** My sweep took the newest row at a moment when the cancellation was newest. 🔑 **This is the same shape as `#1466`'s skipped job, running the other way, and the pair is worth holding together:** ``` skipped -> status success ("Has been skipped") a gate that never ran reads GREEN cancelled -> status failure ("Has been cancelled") a gate that never ran reads RED ``` **On this forge the status value does not distinguish *ran* from *did not run*, in either direction. The `description` field does.** ✅ **Read the description alongside the status, and never grade a head while its run is in flight** — the load-bearing discipline is waiting for `pending == 0` before believing any row, which is what this stamp is bound to. ## The `v0.62.4` cut has a second symptom, and it was in `#1448`'s own diff The pins here move `'main' -> 'v0.63.1'`. On `#1448` they moved `'v0.62.4' -> 'v0.63.0'`. **That difference is the finding:** ``` 494c7785 post-cut bookkeeping for v0.62.2 pin -> 'main' d4917b72 prepare v0.62.3 pin -> 'v0.62.3' 24491072 post-cut bookkeeping for v0.62.3 pin -> 'main' e45075a1 prepare v0.62.4 pin -> 'v0.62.4' — no post-cut bookkeeping for v0.62.4 exists — 4bea5600 prepare v0.63.0 pin -> 'v0.63.0' 454d8095 post-cut bookkeeping for v0.63.0 pin -> 'main' ``` **`prep` bakes the tag, `post-cut` resets to `main`; `main -> v0.63.1` is the healthy cycle.** The `v0.62.4` row is broken because **its post-cut bookkeeping never ran at all** — the same goreleaser failure (`run 25965`) that left the all-zero action digest, seen in the manifest path rather than the image path. 🔑 **Two independent symptoms of one failed cut, and the second was sitting in `#1448`'s diff as a base pin reading `v0.62.4` where every healthy prep reads `main`. Nobody looked at it, including me.** ## ⚠️ The new required context: two placements, one grader — and one state it cannot exit ``` mirror-release.yml rt tag-action-digest-check before the pin PR opens readme-pin-check.yml rt tag-action-digest-check on the pin PR, now REQUIRED ``` **Same verb. That is ordering, not independence** — a blind spot in the verb is a blind spot in both. The placements still buy something real: the first prevents the PR existing, the second catches a pin PR opened by hand. 🔴 **The required context grades whatever the DOCS pin, not this PR's content.** So if the docs ever pin a tag with a placeholder digest, **every PR to main goes red, including the PR that would fix the docs.** ``` today docs pin v0.63.0, real digest, green, no exposure entry only by advancing the docs to a broken tag — set-adopter-pin closes the automatic path; a hand edit of the pin does not recovery admin removes the context, or force-merges the fix. No in-band path, because the fix is itself a PR. ``` **Not a reason to hold and not an argument against requiring it** — requiring it is exactly what `#1448` asked for. **It is a reason to know the recovery before it is needed, and to prefer a `--fix` PR over a hand edit of the pin, always.** ## What `v0.63.1` actually tests, and a cheap check after the cut **The live run of the new gate is not this PR — it is the pin PR that follows the mirror publish.** If `v0.63.1`'s bake fails the way `v0.62.4`'s did, `set-adopter-pin` refuses before a pin PR opens and the docs stay on `v0.63.0`, which has a real digest. 📌 **After the cut, two commands, and they are independent of each other:** ``` git fetch --force --tags then read action.yml at v0.63.1 -> non-placeholder digest? git log --grep='post-cut bookkeeping for v0.63.1' -> does the commit exist? ``` **Those are the two symptoms of the `v0.62.4` failure. Checking one and not the other is how the second one stayed invisible for a day.** --- Bound to `d2749e24`, base `c5142ab1`. **Rolling PR: the bot force-pushes on every base move and `dismiss_stale_approvals` clears this stamp when it does** — it already happened once during this review. Re-ping rather than merging on a dismissed row.

bosun merged commit d2749e2458 into main 2026-09-08 01:19:21 +02:00

forgejo-actions commented 2026-09-08 01:19:33 +02:00

Copy link

Landing identity record

• PR: #1468
• landed commit (server merge_commit_sha): d2749e2458eb363f0e855d6fd89cbccc59b93bd0
• effective official approval(s):
  • @surveyor, review #7070, stamped commit: d2749e2458eb363f0e855d6fd89cbccc59b93bd0
• 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=d2749e2458eb363f0e855d6fd89cbccc59b93bd0 --> ## Landing identity record - PR: #1468 - landed commit (server merge_commit_sha): `d2749e2458eb363f0e855d6fd89cbccc59b93bd0` - effective official approval(s): - @surveyor, review #7070, stamped commit: `d2749e2458eb363f0e855d6fd89cbccc59b93bd0` - 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!1468

No description provided.