Gate final-version docker tags on release publish, not draft by jflo · Pull Request #10306 · besu-eth/besu

jflo · 2026-04-22T15:52:39Z

Summary

Fix a policy bug where draft-release.yml publishes version-specific docker tags (e.g. besu:26.4.0, besu:26.4.0-amd64, besu:26.4.0-arm64) immediately when run — regardless of whether the GitHub release is still in draft. This meant the final docker tag for 26.4.0 became publicly pullable on 2026-04-17, five days before the release was actually published and burn-in signed off. If an RC burn-in had failed, we would have had stale production docker tags pointing to broken code.

Changes

.github/workflows/draft-release.yml — the docker-publish, docker-manifest, and docker-verify jobs now only run when the input tag contains -RC. Running the workflow with an RC tag still pushes the RC-suffixed docker images for burn-in use (26.4.0-RCn, 26.4.0-RCn-amd64, 26.4.0-RCn-arm64). Running with a final tag (26.4.0) skips docker entirely — release-draft artifacts are still produced as before.
.github/workflows/docker-promote.yml — extended from just promoting latest tags to also publishing the version-specific tags. On release publish, the workflow now:
1. Locates the latest RC git tag (<VERSION>-RC<n>) pointing at the release sha
2. Retags the RC's docker images into the version-specific tags AND latest tags using docker buildx imagetools create
3. Verifies version-specific and latest tags
Retagging at the registry level (instead of rebuilding from source) preserves byte-identical manifests — the published binaries are exactly what burn-in validated.

Flow comparison

	Before	After
RC phase: run draft-release with `26.4.0-RC3`	pushes `besu:26.4.0-RC3*`	pushes `besu:26.4.0-RC3*` (same)
Final phase: run draft-release with `26.4.0`	*pushes `besu:26.4.0` publicly (bug)**	skips docker; produces draft release artifacts
Publish release (out of draft)	docker-promote pushes `latest*`	docker-promote retags RC → `besu:26.4.0` and `besu:latest`

Fail-loud on missing RC

If no RC tag matching <VERSION>-RC<n> is found at the release sha, docker-promote fails with a clear error rather than silently skipping the promotion. This enforces the policy that every released version must have gone through an RC.

Test plan

Re-run draft-release on main with a test RC tag (e.g. on a fork) and confirm only RC-suffixed docker tags are pushed
Re-run draft-release with a non-RC tag and confirm docker jobs skip
Trigger a test publish flow in the sandbox repo to validate docker-promote retags correctly
Verify docker buildx imagetools create retagging produces identical manifest digests (no rebuild)

Follow-ups (not in this PR)

Update the internal release playbook / besu-release skill to reflect the new flow (run draft-release with RC tag during burn-in, then with final tag for the release artifacts)
Consider mirroring these changes to the Consensys/protocols-release-sandbox workflows used for simulation

🤖 Generated with Claude Code

Copilot

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates the release workflows so version-specific Docker tags are only published when a GitHub release is published (not while it’s still a draft), by promoting already-burned-in RC images to final tags at publish time.

Changes:

Gate Docker publishing in draft-release.yml to RC tags only (*-RC<n>), skipping Docker for final version tags.
Extend docker-promote.yml to locate the RC tag at the release SHA and retag RC images into versioned and latest tags using registry-level manifest retagging.
Expand docker-verify to validate both version-specific and latest tags across architectures.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
.github/workflows/draft-release.yml	Adds RC-only conditionals to Docker publish/manifest/verify jobs to prevent premature final tag publication.
.github/workflows/docker-promote.yml	Finds the matching RC tag for a published release and retags RC images to final version and `latest` tags, plus broadens verification.

Copilot · 2026-04-22T15:59:20Z

+      - name: Retag RC images as version-specific and latest
+        env:
+          IMAGE: ${{ env.registry }}/${{ secrets.DOCKER_ORG }}/besu
+        run: |
+          set -euxo pipefail
+          # Per-arch single-platform tags: RC-<arch>  ->  <VERSION>-<arch>, latest-<arch>
+          for ARCH in amd64 arm64; do
+            docker buildx imagetools create \


This job uses 'docker buildx imagetools', but there’s no explicit buildx setup step. On some runners (especially self-hosted), buildx may be missing or not configured, which would make promotions flaky. Add an explicit buildx setup step (e.g., docker/setup-buildx-action) before invoking 'docker buildx imagetools create' to make the workflow deterministic across runner environments.

this could be a legit concern on self hosted runners for example. might be worth an extra step to be sure, especially since this would not have triggered for this PR

The draft-release workflow previously pushed version-specific docker tags (e.g. hyperledger/besu:26.4.0) as soon as it ran, regardless of whether the GitHub release was still in draft. For 26.4.0 this meant the final docker tag became publicly pullable before burn-in sign-off; if an RC had failed we'd have had stale production tags pointing to broken code. - draft-release.yml: the docker-publish, docker-manifest, and docker-verify jobs now run only when the input tag contains `-RC`. Running the workflow with an RC tag still pushes 26.4.0-RCn, 26.4.0-RCn-amd64, 26.4.0-RCn-arm64 for burn-in use. Running with a final tag (e.g. 26.4.0) skips docker entirely — the draft release artifacts are still produced. - docker-promote.yml: triggered on `release: released`, it now retags the matching RC images (found by locating the RC git tag pointing at the release sha) into the version-specific tags AND the `latest` tags using `docker buildx imagetools create`. Retagging at the registry level preserves byte-identical manifests — published binaries are exactly what burn-in validated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: jflo <justin+github@florentine.us>

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Justin Florentine <justin+github@florentine.us> Signed-off-by: jflo <justin+github@florentine.us>

…0298) * Add ChaindId, Coinbase, Gaslimit and PrevRandao to EVM v2 Signed-off-by: Ameziane H. <ameziane.hamlat@consensys.net> * Address comments Signed-off-by: Ameziane H. <ameziane.hamlat@consensys.net> --------- Signed-off-by: Ameziane H. <ameziane.hamlat@consensys.net> Signed-off-by: jflo <justin+github@florentine.us>

garyschulte

LGTM, some non-blocking feedback

garyschulte · 2026-04-30T20:08:31Z

+      - name: Retag RC images as version-specific and latest
+        env:
+          IMAGE: ${{ env.registry }}/${{ secrets.DOCKER_ORG }}/besu
+        run: |
+          set -euxo pipefail
+          # Per-arch single-platform tags: RC-<arch>  ->  <VERSION>-<arch>, latest-<arch>
+          for ARCH in amd64 arm64; do
+            docker buildx imagetools create \


this could be a legit concern on self hosted runners for example. might be worth an extra step to be sure, especially since this would not have triggered for this PR

garyschulte · 2026-04-30T20:12:34Z

      - name: Stop container
        run: docker stop ${{ env.CONTAINER_NAME }}

  release-draft:


should we gate this on -RC as well ? it isn't clear what value this step has if we are not releasing

it just creates the usable artifacts, then gives time for the burn-in

Copilot AI review requested due to automatic review settings April 22, 2026 15:52

Copilot AI reviewed Apr 22, 2026

View reviewed changes

jflo and others added 3 commits April 22, 2026 15:18

Update .github/workflows/docker-promote.yml

09d49cb

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Justin Florentine <justin+github@florentine.us> Signed-off-by: jflo <justin+github@florentine.us>

jflo force-pushed the docker-publish-rc-only branch from 2b10913 to 0b761f4 Compare April 22, 2026 19:19

Merge branch 'main' into docker-publish-rc-only

d2ccb57

jflo marked this pull request as draft April 22, 2026 20:00

jflo added 2 commits April 23, 2026 11:01

Merge branch 'main' into docker-publish-rc-only

052b8c2

Merge branch 'main' into docker-publish-rc-only

198af0b

jflo marked this pull request as ready for review April 29, 2026 13:29

Merge branch 'main' into docker-publish-rc-only

f27f1d5

garyschulte approved these changes Apr 30, 2026

View reviewed changes

macfarla approved these changes Apr 30, 2026

View reviewed changes

Comment thread .github/workflows/docker-promote.yml

Merge branch 'main' into docker-publish-rc-only

fe7dbc5

jflo enabled auto-merge (squash) April 30, 2026 20:32

jflo merged commit f3e26cf into besu-eth:main Apr 30, 2026
47 of 49 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Gate final-version docker tags on release publish, not draft#10306

Gate final-version docker tags on release publish, not draft#10306
jflo merged 8 commits into
besu-eth:mainfrom
jflo:docker-publish-rc-only

jflo commented Apr 22, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI Apr 22, 2026

Uh oh!

garyschulte Apr 30, 2026

Uh oh!

Uh oh!

garyschulte left a comment

Uh oh!

garyschulte Apr 30, 2026

Uh oh!

garyschulte Apr 30, 2026

Uh oh!

macfarla Apr 30, 2026

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

jflo commented Apr 22, 2026

Summary

Changes

Flow comparison

Fail-loud on missing RC

Test plan

Follow-ups (not in this PR)

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

garyschulte Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

garyschulte left a comment

Choose a reason for hiding this comment

Uh oh!

garyschulte Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

garyschulte Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

macfarla Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants