feat(dogfood): adopt the docker action in release-toolkit's own workflows #1476

New issue

Open

opened 2026-09-08 13:26:19 +02:00 by bosun · 0 comments

bosun commented

2026-09-08 13:26:19 +02:00

Owner

tags carrying a placeholder digest   14 of 123
consumers using the docker action     0   (every adopter calls a reusable workflow)

The action exists to remove the need to build rt on a foreign Forgejo and is what let the shell scripts retire. Its justification is sound; nothing tests it.

Two constraints that shape the design

It must pin a RELEASED tag, not main. action.yml on main carries the placeholder by construction — the digest is baked at cut time — so a @main pin is permanently broken and tells us nothing.

A broken tag would then break our own CI and our ability to fix it. Same shape as the recovery gap @surveyor named on the required digest context: the gate grades something outside the PR, so a bad value reddens every PR including the fix. Know the recovery before adopting, not during.

Acceptance criteria

At least one release-toolkit workflow obtains rt via uses: frankenbit/release-toolkit@<released tag> rather than building it
The pin advances as part of the existing pin-advance path, not by hand
The recovery path is written down: what to do when the pinned tag turns out to be broken, tested at least once deliberately
A placeholder digest in the pinned tag reddens this repo's CI, verified by pointing it at a known-bad tag such as v0.62.4

Anchor

Operator, 2026-09-08: "would it make sense to adopt it locally? … this would test both the build chain and the docker setup." Filed after the v1.0.0 readiness survey found the surface unused and partially broken.

The docker action has no users, is broken at 14 tags, and nothing exercises it — so adopting it here would test the Go build chain and the docker setup at once, and a placeholder digest would break our own CI immediately instead of silently. ``` tags carrying a placeholder digest 14 of 123 consumers using the docker action 0 (every adopter calls a reusable workflow) ``` The action exists to remove the need to build `rt` on a foreign Forgejo and is what let the shell scripts retire. Its justification is sound; nothing tests it. ## Two constraints that shape the design **It must pin a RELEASED tag, not `main`.** `action.yml` on `main` carries the placeholder by construction — the digest is baked at cut time — so a `@main` pin is permanently broken and tells us nothing. **A broken tag would then break our own CI and our ability to fix it.** Same shape as the recovery gap @surveyor named on the required digest context: the gate grades something outside the PR, so a bad value reddens every PR including the fix. Know the recovery before adopting, not during. ## Acceptance criteria - [ ] At least one release-toolkit workflow obtains `rt` via `uses: frankenbit/release-toolkit@<released tag>` rather than building it - [ ] The pin advances as part of the existing pin-advance path, not by hand - [ ] The recovery path is written down: what to do when the pinned tag turns out to be broken, tested at least once deliberately - [ ] A placeholder digest in the pinned tag reddens this repo's CI, verified by pointing it at a known-bad tag such as `v0.62.4` ## Anchor Operator, 2026-09-08: *"would it make sense to adopt it locally? … this would test both the build chain and the docker setup."* Filed after the v1.0.0 readiness survey found the surface unused and partially broken.

bosun added the

priority/medium

size/M

kind/feature

labels

2026-09-08 13:26:19 +02:00