Publish release images by dispatch, and build them from the tag

Drop the `release:` trigger. GitHub runs a release event's workflow as it exists
at the tag, and the tag is cut at `prepare` while the GitHub Release is published
at `vote-passed`, at least 72 hours later. Anything changed in publish-docker.yaml
inside that window silently does not apply to the release in flight - which is how
9.7.0 published with no workflow run at all, its tag predating the trigger by a
day. The window reopens every release, so the next one only escapes by luck.

`github-release` now dispatches the workflow itself after creating the Release, so
this stays automatic rather than becoming something to remember. A dispatch always
runs the workflow from the default branch, making what publishes a function of
main rather than of when the tag happened to be cut. If the dispatch fails the
release is still published, so it warns with the retry commands instead of
aborting.

Nothing else about the run depends on a branch or on timing. The tree is checked
out at refs/tags/vx.y.z, so Dockerfile and Makefile - which decide what the image
actually is - come from the released source rather than from whatever main looks
like now. The agent package is still the verified tarball from dist/release, and
the image tags come from the version. A leading v on the input is tolerated.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: wu-sheng

.github/workflows/publish-docker.yaml

@@ -24,22 +24,21 @@ name: publish-docker
 #                     tagged x.y.z-<base>, pushed to Docker Hub as
 #                     apache/skywalking-java-agent.
 #
-# The release trigger is `released` rather than `published`, so publishing a
-# pre-release does not ship official images. Creating the GitHub Release is the
-# last step of `tools/releasing/release.sh vote-passed`.
+# Releases publish by dispatch, deliberately, rather than by a `release` trigger.
+# For a `release` event GitHub runs the workflow as it exists **at the tag**, and
+# the tag is cut at `prepare` while the GitHub Release is published at
+# `vote-passed`, at least 72 hours later. Anything changed here in between would
+# silently not apply to the release in flight - that window is how 9.7.0 shipped
+# with no workflow run at all. A dispatch always runs the workflow from the
+# default branch, so what is on main is what publishes.
 #
-# workflow_dispatch is the way to publish when the release trigger cannot fire.
-# For a `release` event GitHub runs the workflow as it exists **at the tag**, so a
-# tag cut before this trigger was added produces no run at all - which is what
-# happened to 9.7.0. A dispatch always runs the workflow from the default branch,
-# so it is also the way to retry a release whose images failed to push.
+# `release.sh github-release` creates the Release and then dispatches this
+# workflow, so this stays automatic; running it by hand from the Actions tab is
+# how you retry a release whose images failed to push.
 on:
   push:
     branches:
       - main
-  release:
-    types:
-      - released
   workflow_dispatch:
     inputs:
       version:
@@ -49,9 +48,9 @@ on:
 
 env:
   SKIP_TEST: true
-  # Non-empty exactly when this run publishes an official release, from either
-  # trigger. Everything below keys off this rather than the event name.
-  RELEASE_TAG: ${{ github.event.release.tag_name || github.event.inputs.version }}
+  # Non-empty exactly when this run publishes an official release. Everything
+  # below keys off this rather than the event name.
+  RELEASE_TAG: ${{ github.event.inputs.version }}
 
 jobs:
   # One agent package feeds every image. The variants differ only in the JRE they
@@ -134,11 +133,25 @@ jobs:
         # A release publishes the complete set the previous manual `make
         # docker.push.*` produced, alpine included. Per-commit development
         # images keep the existing JRE-only set.
-        base: ${{ (github.event.release.tag_name || github.event.inputs.version) && fromJSON('["alpine","java8","java11","java17","java21","java25"]') || fromJSON('["java8","java11","java17","java21","java25"]') }}
+        base: ${{ github.event.inputs.version && fromJSON('["alpine","java8","java11","java17","java21","java25"]') || fromJSON('["java8","java11","java17","java21","java25"]') }}
     steps:
       - uses: actions/checkout@v2
         with:
           submodules: true
+      # The workflow file necessarily comes from the default branch on a
+      # dispatch - that is the point, it is what makes the run deterministic. The
+      # tree it builds must not. Dockerfile and Makefile decide what the image
+      # actually is, so for a release take them from the tag, exactly as the
+      # release:perform build and the source tarball did.
+      - name: Check out the released tag
+        if: env.RELEASE_TAG != ''
+        run: |
+          set -euo pipefail
+          VERSION=${RELEASE_TAG#v}
+          git fetch --depth 1 origin "refs/tags/v${VERSION}:refs/tags/v${VERSION}"
+          git checkout "refs/tags/v${VERSION}"
+          git submodule update --init --depth 1
+          git --no-pager log -1 --format='building from %h %d'
       - uses: actions/download-artifact@v4
         with:
           name: skywalking-agent

docs/en/contribution/release-java-agent.md

@@ -134,22 +134,25 @@ After the vote passes, run `vote-passed` which executes:
 4. **cleanup** (optional) — if old version is provided, remove it from `dist/release`. Update download page links to point to `https://archive.apache.org/dist/skywalking`
 
 ### Docker images
-Docker images are published by GitHub Actions, not from your machine. Publishing the
-GitHub Release normally fires the `release: released` trigger in
-[`.github/workflows/publish-docker.yaml`](../../../.github/workflows/publish-docker.yaml),
-which builds every base variant and pushes
+Docker images are published by GitHub Actions, not from your machine. `github-release`
+publishes the GitHub Release and then dispatches
+[`.github/workflows/publish-docker.yaml`](../../../.github/workflows/publish-docker.yaml)
+with the release version. It builds every base variant and pushes
 `apache/skywalking-java-agent:x.y.z-{alpine,java8,java11,java17,java21,java25}` to Docker
 Hub for `linux/amd64` and `linux/arm64`. Watch that workflow.
 
-If it does not start, or it fails, run it by hand: **Actions → publish-docker → Run
-workflow**, entering the version (`9.7.0`). A dispatch always runs the workflow from the
-default branch and does the same download-and-verify, so it is the normal way to retry.
+If it fails, run it again: **Actions → publish-docker → Run workflow**, entering the
+version (`9.7.0`). That is the same path `github-release` takes, so retrying is safe and
+idempotent.
 
 > [!NOTE]
-> For a `release` event GitHub runs the workflow **as it exists at the tag**, not as it
-> exists on `main`. A tag cut before a trigger was added to `publish-docker.yaml` therefore
-> produces no run at all — this is exactly what happened to 9.7.0, whose tag predates the
-> release trigger. Use the manual dispatch in that case.
+> There is deliberately **no `release:` trigger**. GitHub runs a release event's workflow as
+> it exists *at the tag*, and the tag is cut at `prepare` while the Release is published at
+> `vote-passed`, at least 72 hours later — so any change to the workflow in between would
+> silently not apply to the release in flight. That window is why 9.7.0 published with no
+> workflow run at all. Dispatching instead means the workflow always comes from `main`,
+> while everything it acts on comes from the tag: the tree it builds is checked out at
+> `vx.y.z`, and the agent package is the verified tarball from `dist/release`.
 
 As a last resort you can push from your machine with
 `./tools/releasing/release.sh docker x.y.z`, which needs you to be logged in to Docker Hub

tools/releasing/release.sh

@@ -689,11 +689,26 @@ cmd_github_release() {
     fi
 
     gh release create "${tag}" --title "${version}" "${notes_args[@]}"
-
     info "GitHub Release ${tag} published."
-    info "  publish-docker.yaml is now pushing to Docker Hub:"
-    info "    apache/skywalking-java-agent:${version}-{alpine,java8,java11,java17,java21,java25}"
-    info "  Watch: https://github.com/apache/skywalking-java/actions/workflows/publish-docker.yaml"
+
+    # Dispatch rather than let a `release` trigger fire. GitHub runs a release
+    # event's workflow as it exists at the tag, and the tag is cut at `prepare`
+    # while this runs at `vote-passed`, at least 72 hours later - anything
+    # changed in publish-docker.yaml in between would silently not apply. A
+    # dispatch always runs the workflow from the default branch, so the release
+    # publishes with what is on main, and builds from the tag.
+    info "Dispatching publish-docker for ${version}..."
+    if gh workflow run publish-docker.yaml -f version="${version}"; then
+        info "  Pushing to Docker Hub:"
+        info "    apache/skywalking-java-agent:${version}-{alpine,java8,java11,java17,java21,java25}"
+        info "  Watch: https://github.com/apache/skywalking-java/actions/workflows/publish-docker.yaml"
+    else
+        warn "  Could not dispatch publish-docker. The release itself is published;"
+        warn "  only the images are missing. Retry with:"
+        warn "    gh workflow run publish-docker.yaml -f version=${version}"
+        warn "  or from Actions -> publish-docker -> Run workflow, or as a last resort"
+        warn "    $0 docker ${version}"
+    fi
 }
 
 # ============================================================