Publish release images by dispatch, built from the tag

[wu-sheng]

Problem

Publishing the 9.7.0 GitHub Release produced no workflow run at all — not a failed one,
nothing — and the images were never pushed to Docker Hub.

For a release event GitHub runs the workflow as it exists at the tag, not as it exists
on the default branch:

tag v9.7.0 -> 7a6c1e46c9, 2026-08-12 15:24
  on: push: branches: [main]                 # no release trigger

main -> afede1badd (#821), 2026-08-13 06:41
  on: push + release: types: [released]

#821 is not an ancestor of the tag, so GitHub read v9.7.0's copy of the workflow, found
no release trigger, and correctly did nothing.

This is not a one-off. The tag is cut at prepare; the Release is published at
vote-passed, at least 72 hours later. Any change to publish-docker.yaml merged in
that window silently does not apply to the release in flight. The window reopens every
release — 9.7.0 was simply the first time something landed inside it.

Confirmed against apache/skywalking, where the same trigger works because it was added in
2023, long before any current tag:

repo	trigger added	tags	fires?
apache/skywalking	2023-03-08	v10.2.0 … v10.4.0 (2025–2026)	yes
skywalking-java	2026-08-13	v9.7.0 (2026-08-12)	no

Fix

Remove the release: trigger and dispatch instead. github-release now creates the Release
and then runs:

gh workflow run publish-docker.yaml -f version="${version}"

so publishing stays automatic rather than becoming something to remember. A dispatch always
runs the workflow from the default branch, which makes what publishes a function of main
rather than of when the tag happened to be cut. If the dispatch fails the Release is already
published, so the script warns with retry commands rather than aborting.

Everything the run acts on comes from the tag, not from a branch or a timestamp:

	source
workflow file	default branch — deliberately, this is what makes it deterministic
build tree	git checkout refs/tags/vx.y.z — Dockerfile and Makefile from the released source
agent payload	dist/release/<version> tarball, sha512 + GPG verified
image tags	the version input

The tag checkout matters: Dockerfile and Makefile decide what the image actually is, and
previously a dispatch would have built with main's copies.

input	tag	dist path	image
9.7.0	refs/tags/v9.7.0	.../java-agent/9.7.0	:9.7.0-alpine
v9.7.0	refs/tags/v9.7.0	.../java-agent/9.7.0	:9.7.0-alpine

Leaving the input blank builds a development image, matching a push to main.

Recovering 9.7.0

Once this merges: Actions → publish-docker → Run workflow, enter 9.7.0. Same
verification, on CI, with a record of what ran — better than pushing from a workstation.

Testing

• Workflow YAML parses; bash -n clean; env used only in step-level if:, where that
  context exists.
• dist/release URLs verified live after promote (.tgz, .asc, .sha512 all HTTP 200;
  dist/dev now 404).
• refs/tags/v9.7.0 resolves, so the tag checkout will succeed.
• Version normalisation verified for both 9.7.0 and v9.7.0.

🤖 Generated with Claude Code