chore(readme): point the adopter pin at the newest servable release #1464
No reviewers
Labels
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
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit!1464
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "chore/readme-pin-20260907215900"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Opened by
mirror-release.ymlafter a successful mirror publish (release-toolkit#1378). The adopter-facing pins inREADME.md,docs/integration.mdandexamples/**are set by the MIRROR rather than by the cut, because only the mirror knows when a version becomes fetchable.rt readme-pin-check --fixcomputed the target with the same code that grades it. Read the diff: this changes what a stranger is told to pin.no-changelog: docs currency -- this PR only re-points adopter pins at the release that just published, and a fragment here would describe that release in the NEXT one's notes.
APPROVE — reviewed at
0e7f2b0ace541e8c761c5b2c50354a60b75f3277. All 28 contexts green at that head;tests / batshas since landed.① The
#1435check, re-run rather than assumed✅ Every token the bot moved was
@-prefixed and it touched no bare version, so#1423's hazard —docs/integration.mdbeing mostly history — is not tripped. Same property, same file set, same verdict as#1435.② The digests, read from the API at each tag — never from a clone
Per your
git fetch --tagswarning, I readcontents/action.yml?ref=<tag>so a stale local ref could not answer:🔴 So this is a REPAIR, not currency. The pin being left is the
#1210failure mode:v0.62.4is servable on the mirror —HTTP 200, 3 assets — so the reference resolves and the checkout succeeds, and the run then dies pullingsha256:0000…. A green reference with a broken image behind it. "Nothing is broken; this is currency" is true of most runs of this bot and is NOT true of this one.Mirror servability of the arriving pin, checked too:
v0.63.0→HTTP 200, 3 assets.📌 One instrument note, because it nearly went into this stamp as a number
My first digest read returned
sha256:with no hex and I was one keystroke from reporting could not read for both tags. The cause washead -1on an unanchored match:action.yml's comment block mentions "pinned to an image DIGEST" four lines above theimage:line, so the firstsha256-ish hit was prose. ✅ Anchoring on^\s*image:and requiring[0-9a-f]{64}is what makes the read structural rather than positional — the first match is not the right match, it is only the first.⚠️ Scope of this stamp
I graded what the diff moves and what the two pins point at. I did not re-derive the mirror-servability half of
readme-pin-check, which is that job's own business and green here — and per#1463the two graders are still bundled, so this context's green is a conjunction rather than a single fact.Landing identity record
0e7f2b0ace541e8c761c5b2c50354a60b75f32770e7f2b0ace541e8c761c5b2c50354a60b75f3277This 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.