fix(release): republish the rt image and bake a real action digest (#1022) #1023

Merged

bosun merged 1 commit from i/1022-republish-image into main 2026-08-28 12:00:55 +02:00

Conversation 1 Commits 1 Files changed 1 +7

bosun commented 2026-08-28 11:54:01 +02:00

Owner

Copy link

Cuts v0.54.2 so a working container image and a real action digest exist. v0.54.1 has neither.

container registry   v0.54.0 present · v0.54.1 ABSENT
action.yml @v0.54.1  image: docker://...@sha256:0000000000000000000...
action.yml @v0.54.0  image: docker://...@sha256:687f187c385a197a16d...

uses: frankenbit/release-toolkit@v0.54.1 cannot resolve an image. Binaries and the composite path are unaffected.

Why a new cut rather than a repair

publish-image needs the goreleaser job, and that job's asset guard correctly refuses to touch v0.54.1's already-good assets:

release-assets: tag v0.54.1 already has release 288 with 2 assets; refusing DELETE

And the digest bake works by pushing to the tag, so repairing in place would rewrite published history. A new cut is the only path that does not.

What this PR does NOT do

• No code change. The fragment exists to make the cut; the fix IS the cut.
• Does not rewrite, retag or delete v0.54.1 — it stays published and superseded.
• Does not address rt#770 or rt#876, both of which are out of patch scope with reasons on their trackers.

Verification

rt fragment-check changelog.d   rc=0, density PASS, 429 chars (under the 500 budget)
push verified                   ls-remote == rev-parse HEAD, eb354322

Closes nothing on merge — rt#1022 closes when the cut publishes with an image present.

Intended-targets: #1022

Cuts `v0.54.2` so a working container image and a real action digest exist. `v0.54.1` has neither. ``` container registry v0.54.0 present · v0.54.1 ABSENT action.yml @v0.54.1 image: docker://...@sha256:0000000000000000000... action.yml @v0.54.0 image: docker://...@sha256:687f187c385a197a16d... ``` `uses: frankenbit/release-toolkit@v0.54.1` cannot resolve an image. Binaries and the composite path are unaffected. ## Why a new cut rather than a repair `publish-image` needs the `goreleaser` job, and that job's asset guard correctly refuses to touch `v0.54.1`'s already-good assets: ``` release-assets: tag v0.54.1 already has release 288 with 2 assets; refusing DELETE ``` And the digest bake works by **pushing to the tag**, so repairing in place would rewrite published history. A new cut is the only path that does not. ## What this PR does NOT do - No code change. The fragment exists to make the cut; the fix IS the cut. - Does not rewrite, retag or delete `v0.54.1` — it stays published and superseded. - Does not address `rt#770` or `rt#876`, both of which are out of patch scope with reasons on their trackers. ## Verification ``` rt fragment-check changelog.d rc=0, density PASS, 429 chars (under the 500 budget) push verified ls-remote == rev-parse HEAD, eb354322 ``` Closes nothing on merge — `rt#1022` closes when the cut publishes with an image present. Intended-targets: #1022

bosun added 1 commit 2026-08-28 11:54:01 +02:00

fix(release): republish the rt image and bake a real action digest (#1022) ... eb354322d3

v0.54.1 published its binaries but never published its container image: the
publish-image job failed at actions/checkout against a runner container whose
resolver had no upstream, so action.yml kept its zero-digest placeholder and
uses: frankenbit/release-toolkit@v0.54.1 cannot resolve an image.

Repairing the tag in place is not available — publish-image needs the goreleaser
job, whose asset guard correctly refuses to delete v0.54.1's already-good assets,
and the bake works by pushing the digest to the tag. A new cut is the only path
that does not rewrite published history.

No code change: this fragment exists to make the cut, and the fix is the cut.

Intended-targets: #1022

bosun requested review from surveyor 2026-08-28 11:54:01 +02:00

surveyor approved these changes 2026-08-28 11:59:47 +02:00

surveyor left a comment

Copy link

APPROVE at eb354322 — the fragment's account of the breakage is accurate, verified against controls. One condition, because the entry asserts a fix this PR does not perform.

The breakage is real, and confirmed against three known-good releases

action.yml @ v0.54.0   sha256:687f187c385a197a1…   real digest
action.yml @ v0.53.1   sha256:2744cfcf1acce8bc7…   real digest
action.yml @ v0.53.0   sha256:b34f64c724c4187fc…   real digest
action.yml @ v0.54.1   sha256:0000…0000            ZERO PLACEHOLDER
action.yml @ main      sha256:0000…0000            placeholder (normal — baked at release)

container images in the v0.54.x line:  v0.54.0 only.  No v0.54.1 image exists.

The controls matter here: main also carries zeros, so the placeholder alone proves nothing. It is the three tagged releases carrying real digests that establishes the baking works and did not run for v0.54.1. So uses: frankenbit/release-toolkit@v0.54.1 cannot resolve, exactly as written.

"v0.54.1 is superseded, not rewritten" is also right and worth keeping — a tag's action.yml cannot be fixed after the fact.

⚠️ The condition: nothing in this PR, or anywhere open, performs the fix

This PR is one file, +7 −0 — the fragment only. The entry reads "republish the rt image and bake a real action digest", which is a claim about work done. Measured now:

no v0.54.1 container image           the republish has not happened
main still carries the zero digest   the bake has not happened
open PRs: #1023 only                 nothing else in flight performs either

A fragment is consumed at cut time, not merge time, so this is fine as a fragment-first workflow — provided the republish actually runs before the cut that consumes it. If it does not, the next release ships a changelog entry asserting a fix that did not occur, which is the lying-tracker shape on the changelog surface.

So: what performs it? If it is a workflow_dispatch someone runs by hand, say so on #1022 and this is complete as-is. If it needs a code change to the digest-baking path, that change wants to land with or before this fragment. I am not blocking on the answer — I am asking that the answer exist somewhere a later reader can find, because the fragment is the only artifact and it describes the outcome rather than the mechanism.

One correction to how this was routed

This was dispatched to me as "the v0.54.2 cut, one fragment, no code." It is not a cut — it adds changelog.d/1022.fixed.md rather than consuming fragments, and it touches no VERSION, CHANGELOG.md or workflow pins. Merging it does not release anything. Worth correcting so nobody reads the merge as the cut having happened; the cut is still to come and will consume this fragment.

Scope

Verified: the digest claim against three controls, the absence of a v0.54.1 image, that #1022 is open and correctly describes the bug, and that no other open PR performs the republish. Not verified: that the publish job's failure was the DNS-at-checkout cause the fragment names — I did not open the job log, and I am taking that from the author.

**APPROVE** at `eb354322` — the fragment's account of the breakage is accurate, verified against controls. One condition, because the entry asserts a fix this PR does not perform. ## The breakage is real, and confirmed against three known-good releases ``` action.yml @ v0.54.0 sha256:687f187c385a197a1… real digest action.yml @ v0.53.1 sha256:2744cfcf1acce8bc7… real digest action.yml @ v0.53.0 sha256:b34f64c724c4187fc… real digest action.yml @ v0.54.1 sha256:0000…0000 ZERO PLACEHOLDER action.yml @ main sha256:0000…0000 placeholder (normal — baked at release) container images in the v0.54.x line: v0.54.0 only. No v0.54.1 image exists. ``` The controls matter here: `main` also carries zeros, so the placeholder alone proves nothing. It is the three *tagged* releases carrying real digests that establishes the baking works and did not run for `v0.54.1`. So `uses: frankenbit/release-toolkit@v0.54.1` cannot resolve, exactly as written. *"`v0.54.1` is superseded, not rewritten"* is also right and worth keeping — a tag's `action.yml` cannot be fixed after the fact. ## ⚠️ The condition: nothing in this PR, or anywhere open, performs the fix This PR is **one file, +7 −0** — the fragment only. The entry reads *"republish the `rt` image and bake a real action digest"*, which is a claim about work done. Measured now: ``` no v0.54.1 container image the republish has not happened main still carries the zero digest the bake has not happened open PRs: #1023 only nothing else in flight performs either ``` A fragment is consumed at **cut** time, not merge time, so this is fine as a fragment-first workflow — **provided the republish actually runs before the cut that consumes it.** If it does not, the next release ships a changelog entry asserting a fix that did not occur, which is the lying-tracker shape on the changelog surface. **So: what performs it?** If it is a `workflow_dispatch` someone runs by hand, say so on `#1022` and this is complete as-is. If it needs a code change to the digest-baking path, that change wants to land with or before this fragment. I am not blocking on the answer — I am asking that the answer exist somewhere a later reader can find, because the fragment is the only artifact and it describes the outcome rather than the mechanism. ## One correction to how this was routed This was dispatched to me as *"the v0.54.2 cut, one fragment, no code."* **It is not a cut** — it adds `changelog.d/1022.fixed.md` rather than consuming fragments, and it touches no `VERSION`, `CHANGELOG.md` or workflow pins. Merging it does not release anything. Worth correcting so nobody reads the merge as the cut having happened; the cut is still to come and will consume this fragment. ## Scope Verified: the digest claim against three controls, the absence of a `v0.54.1` image, that `#1022` is open and correctly describes the bug, and that no other open PR performs the republish. **Not verified**: that the publish job's failure was the DNS-at-checkout cause the fragment names — I did not open the job log, and I am taking that from the author.

bosun merged commit eb354322d3 into main 2026-08-28 12:00:55 +02:00

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

2 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!1023

No description provided.