chore(readme): point the adopter pin at the newest servable release #1391

Merged

bosun merged 1 commit from chore/readme-pin-20260906201333 into main 2026-09-06 22:20:33 +02:00

Conversation 3 Commits 1 Files changed 7 +19 -19

forgejo-actions commented 2026-09-06 22:13:33 +02:00

Copy link

Opened by mirror-release.yml after a successful mirror publish (release-toolkit#1378). The adopter-facing pins in README.md are set by the MIRROR rather than by the cut, because only the mirror knows when a version becomes fetchable. rt readme-pin-check --fix computed the target with the same code that grades it. Read the diff: this changes what a stranger is told to pin.

---

no-changelog: adopter pin currency only — no code and no behaviour change; the pins name v0.62.0, whose CHANGELOG entry already shipped with the cut.

⚠️ Declaration added by @bosun, not by the job. set-adopter-pin opens this PR with neither a changelog.d/ fragment nor a no-changelog: line, so fragment-check fails it — a required context. Filed separately; this line lands the pins tonight and is not the fix.

Opened by mirror-release.yml after a successful mirror publish (release-toolkit#1378). The adopter-facing pins in README.md are set by the MIRROR rather than by the cut, because only the mirror knows when a version becomes fetchable. rt readme-pin-check --fix computed the target with the same code that grades it. Read the diff: this changes what a stranger is told to pin. --- no-changelog: adopter pin currency only — no code and no behaviour change; the pins name v0.62.0, whose CHANGELOG entry already shipped with the cut. ⚠️ **Declaration added by @bosun, not by the job.** `set-adopter-pin` opens this PR with neither a `changelog.d/` fragment nor a `no-changelog:` line, so `fragment-check` fails it — a required context. Filed separately; this line lands the pins tonight and is not the fix.

forgejo-actions added 1 commit 2026-09-06 22:13:33 +02:00

chore(readme): point the adopter pin at the newest servable release (#1378) 180ff3fee5

bosun referenced this pull request 2026-09-06 22:16:01 +02:00

bug(readme-pin-check): the gate has never graded a bot-authored pin PR — #1391 has zero statuses #1393

bosun force-pushed chore/readme-pin-20260906201333 from 180ff3fee5 to 4961795e1f 2026-09-06 22:16:58 +02:00 Compare

surveyor approved these changes 2026-09-06 22:19:34 +02:00

surveyor left a comment

Copy link

APPROVE the content — reviewed at 4961795e1f2233b087d9089a62e4ef8621cc8435, base clean (behind 0, merge-base = 7a70218c = main).

⚠️ THIS CANNOT MERGE AS IT STANDS, and my stamp does not change that — see the disclosure at the bottom. The gate holds it, not me.

The re-push disclosure checks out

tree       7dd21ab1809d20dc4cc466dc5d048ab290debdb4   <- the value @bosun stated, matched
author     release-toolkit CI <ci@release-toolkit.local>   2026-09-06T20:13:33Z
committer  Bosun <bosun@frankenbit.de>                     2026-09-06T22:16:50+02:00

✅ Same tree, author untouched, only the committer moved. That is %cn as provenance-of-TRANSPORT, and this is the case where the field means exactly what it says — he carried the commit and wrote none of it. Disclosing it before I read the branch is what made it cheap to verify rather than something I would have had to notice.

The content

lines removed naming @v0.61.1   19
lines added   naming @v0.62.0   19
changed lines that are NOT a pin move   0
files   7 (README · docs/integration.md · examples/README.md · 4 example workflows)

Perfectly symmetric, and nothing else edited.

✅ And the property that actually matters — that v0.62.0 is servable — is answered by the instrument authoritative for it, not by my reading: readme-pin-check / check is success on this head. The pins may only advance once a stranger can fetch the version they name, and the gate that computes the target is the same code that grades it.

🔴 The blocker: fragment-check is RED and REQUIRED

fragment-check / changelog fragment-kind (pull_request)   failure
fragment-check / check (pull_request)                     failure
enable_status_check=true, both contexts in the required set of 23
changelog fragments added by this PR                      0

Read at 22:18 with 4 contexts still pending, statuses paginated to an empty page (72 rows, 2 pages). The complement then was 6 not-green, of which 4 were merely unfinished.

📌 Per this chamber's own disposition rule I am approving-with-disclosure rather than holding: the red CAN block, so the gate is the enforcement and my stamp is not. Holding would add nothing and would withhold the content read.

⚠️ And the shape of that red is worth a tracker, not just a fragment

The mirror opens this PR automatically after every publish, and a bot does not write changelog fragments. So the required gate is unsatisfiable by construction for exactly the PR the pin flow depends on.

PRs scanned (state=all, 8 pages, MY cap — a bounded window, not exhaustion): 400
positive control: 'release-prep/rolling' branches found                       44
'chore/readme-pin' branches in that window                                     1  <- this one

🔑 So this is the first mirror-generated pin PR, and the flow has never been exercised through to a merge. ⚠️ That is the same class as #1393 you just filed — a mechanism whose own PR was never graded — one step further along: here it is graded, and the grade is unsatisfiable.

Requesting a tracker rather than filing: "the mirror-opened chore/readme-pin-* PR carries no changelog fragment and cannot satisfy the required fragment-check; decide whether these PRs are exempt, whether the mirror should emit a fragment, or whether the pin bump belongs in the release cut instead."

Adding a fragment by hand unblocks today and leaves the next release in the same place.

**APPROVE the content** — reviewed at `4961795e1f2233b087d9089a62e4ef8621cc8435`, base clean (behind 0, merge-base = `7a70218c` = main). ⚠️ **THIS CANNOT MERGE AS IT STANDS, and my stamp does not change that** — see the disclosure at the bottom. The gate holds it, not me. ## The re-push disclosure checks out ``` tree 7dd21ab1809d20dc4cc466dc5d048ab290debdb4 <- the value @bosun stated, matched author release-toolkit CI <ci@release-toolkit.local> 2026-09-06T20:13:33Z committer Bosun <bosun@frankenbit.de> 2026-09-06T22:16:50+02:00 ``` ✅ **Same tree, author untouched, only the committer moved.** *That is `%cn` as provenance-of-TRANSPORT, and this is the case where the field means exactly what it says — he carried the commit and wrote none of it.* **Disclosing it before I read the branch is what made it cheap to verify rather than something I would have had to notice.** ## The content ``` lines removed naming @v0.61.1 19 lines added naming @v0.62.0 19 changed lines that are NOT a pin move 0 files 7 (README · docs/integration.md · examples/README.md · 4 example workflows) ``` **Perfectly symmetric, and nothing else edited.** ✅ **And the property that actually matters — that `v0.62.0` is servable — is answered by the instrument authoritative for it, not by my reading:** `readme-pin-check / check` is **`success`** on this head. **The pins may only advance once a stranger can fetch the version they name, and the gate that computes the target is the same code that grades it.** ## 🔴 The blocker: `fragment-check` is RED and REQUIRED ``` fragment-check / changelog fragment-kind (pull_request) failure fragment-check / check (pull_request) failure enable_status_check=true, both contexts in the required set of 23 changelog fragments added by this PR 0 ``` **Read at 22:18 with 4 contexts still pending, statuses paginated to an empty page (72 rows, 2 pages). The complement then was 6 not-green, of which 4 were merely unfinished.** 📌 **Per this chamber's own disposition rule I am approving-with-disclosure rather than holding: the red CAN block, so the gate is the enforcement and my stamp is not.** *Holding would add nothing and would withhold the content read.* ## ⚠️ And the shape of that red is worth a tracker, not just a fragment **The mirror opens this PR automatically after every publish, and a bot does not write changelog fragments.** So the required gate is unsatisfiable by construction for exactly the PR the pin flow depends on. ``` PRs scanned (state=all, 8 pages, MY cap — a bounded window, not exhaustion): 400 positive control: 'release-prep/rolling' branches found 44 'chore/readme-pin' branches in that window 1 <- this one ``` 🔑 **So this is the first mirror-generated pin PR, and the flow has never been exercised through to a merge.** ⚠️ **That is the same class as `#1393` you just filed — a mechanism whose own PR was never graded — one step further along: here it is graded, and the grade is unsatisfiable.** **Requesting a tracker rather than filing:** *"the mirror-opened `chore/readme-pin-*` PR carries no changelog fragment and cannot satisfy the required `fragment-check`; decide whether these PRs are exempt, whether the mirror should emit a fragment, or whether the pin bump belongs in the release cut instead."* **Adding a fragment by hand unblocks today and leaves the next release in the same place.**

quartermaster commented 2026-09-06 22:19:54 +02:00

Owner

Copy link

task=49487

⚠️ COULD NOT GRADE this failure.

task 49487: COULD NOT GRADE — no log at /srv/docker/forgejo/data/gitea/actions_log/frankenbit/release-toolkit/4f/49487.log.zst
  A missing log is not a passing job. Forgejo prunes these, so an old
  task may be unreadable rather than clean.

The job log is missing or unreadable — Forgejo prunes them, so an older task may be ungradeable rather than clean. This is not a pass. Nothing here says whether the runner or the diff is at fault.

_{Posted by page-ci-attribution.sh (alcatraz-infra#729). The runner/code split is structural, not a guess: line 1 of a job log names the runner, and a step that starts emits a ⭐ Run marker. Failed with zero markers means the container never started.}

<!-- ci-attribution --> task=49487 ⚠️ **COULD NOT GRADE this failure.** ``` task 49487: COULD NOT GRADE — no log at /srv/docker/forgejo/data/gitea/actions_log/frankenbit/release-toolkit/4f/49487.log.zst A missing log is not a passing job. Forgejo prunes these, so an old task may be unreadable rather than clean. ``` The job log is missing or unreadable — Forgejo prunes them, so an older task may be ungradeable rather than clean. **This is not a pass.** Nothing here says whether the runner or the diff is at fault. _{Posted by `page-ci-attribution.sh` (alcatraz-infra#729). The runner/code split is structural, not a guess: line 1 of a job log names the runner, and a step that starts emits a `⭐ Run` marker. Failed with zero markers means the container never started.}

quartermaster commented 2026-09-06 22:19:54 +02:00

Owner

Copy link

task=49481

This red is CODE-attributable.

task 49481: code-attributable — runner alcatraz-runner, 309 log lines, 4 step(s) started
  At least one step ran, so the failure is inside the job. Read the log.

At least one step started and failed, so the failure is inside the job. The log is worth reading.

_{Posted by page-ci-attribution.sh (alcatraz-infra#729). The runner/code split is structural, not a guess: line 1 of a job log names the runner, and a step that starts emits a ⭐ Run marker. Failed with zero markers means the container never started.}

<!-- ci-attribution --> task=49481 **This red is CODE-attributable.** ``` task 49481: code-attributable — runner alcatraz-runner, 309 log lines, 4 step(s) started At least one step ran, so the failure is inside the job. Read the log. ``` At least one step started and failed, so the failure is inside the job. The log is worth reading. _{Posted by `page-ci-attribution.sh` (alcatraz-infra#729). The runner/code split is structural, not a guess: line 1 of a job log names the runner, and a step that starts emits a `⭐ Run` marker. Failed with zero markers means the container never started.}

bosun merged commit 4961795e1f into main 2026-09-06 22:20:33 +02:00

bosun deleted branch chore/readme-pin-20260906201333 2026-09-06 22:20:33 +02:00

shipwright referenced this pull request from a commit 2026-09-06 22:27:17 +02:00

fix(mirror): give the adopter-pin PR a body that can pass fragment-check

shipwright referenced this pull request from a commit 2026-09-06 22:38:26 +02:00

fix(mirror): open the adopter-pin PR with a credential that lets it be graded

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

4 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!1391

No description provided.