Release tooling: tag-based versioning, milestone prompt, and Docker images via GitHub Actions

[wu-sheng]

Supersedes #820, which is folded in here. Three fixes to the release flow, all hit while
releasing 9.7.0.

---

1. Identify the release by its tag, not the checked-out branch

Every step after prepare derived the version from the working branch:

version=$(git describe --tags --abbrev=0 | sed 's/^v//')

Release tags are created on release/x.y.z and never become ancestors of main, so
git describe cannot see them from main. By the time vote-passed runs — days later,
after the release PR is merged and the branch auto-deleted — describe walks straight past
every release tag to an unrelated ancient one:

$ git describe --tags --abbrev=0 origin/main
v3.2.6

Not a loud failure: promote would svn mv a 3.2.6 path, and docker would push
apache/skywalking-java-agent:3.2.6-* to Docker Hub under real-looking version tags.

The tag is the only thing that still pins a release once the branch is gone, and it is
already what the rest of the flow acts on — release:perform builds from it, the source
tar is cut from it, the vote email quotes its commit IDs. resolve_version() now takes an
explicit argument, else $RELEASE_VERSION, else the highest vX.Y.Z tag; it validates the
shape and refuses to run when the tag does not exist. Wired into stage, upload,
email, promote, docker, each of which accepts an optional version argument.

vote-passed also prints what it is about to publish and asks for confirmation, since SVN
dist/release and Docker Hub are both public and awkward to walk back.

2. Prompt for the next milestone ID (was #820)

Resetting CHANGES.md for the next development version wrote a placeholder nothing ever
filled in:

All issues and pull requests are [here](https://github.com/apache/skywalking/milestone/xxx?closed=1)

Unless the release manager spotted it, the placeholder rode the release PR into main and
the next change log shipped pointing at a dead link — which is what happened for 9.7.0 and
had to be corrected by hand.

prepare now asks for the ID, up front next to the version confirmation rather than after
the multi-minute release:prepare build. The answer is validated as numeric and
cross-checked against the milestone title on apache/skywalking, so reusing last release's
ID is caught:

[WARN]   Milestone 249 is 'Java - 9.7.0', expected 'Java - 9.8.0'. Double-check it.

NEXT_MILESTONE=<id> answers non-interactively; a blank answer keeps the old placeholder
behaviour but now warns.

3. Publish release Docker images from GitHub Actions

Official images were pushed by the release manager running make docker.push.* locally: a
multi-arch build of six variants on a laptop, over whatever network it happens to be on,
with a personal Docker Hub session and no record of what ran.

publish-docker.yaml already builds these images on every push to main — it just sends
them to ghcr.io tagged with the commit SHA. It now also has a release: released trigger
whose path targets Docker Hub, matching apache/skywalking. Published tags are unchanged:

apache/skywalking-java-agent:x.y.z-{alpine,java8,java11,java17,java21,java25}

• Trigger is released, not published, so a pre-release does not ship official images.
• The matrix gains alpine on releases only; per-commit development images are untouched.
• QEMU and buildx are set up explicitly, since the Makefile builds linux/amd64 and linux/arm64.

Creating the GitHub Release is what fires it, so that becomes a release step:
github-release publishes the tag using changes/changes-x.y.z.md as its notes, and
vote-passed runs it where it used to run docker. docker remains as a documented
fallback.

Important

This needs DOCKERHUB_USER and DOCKERHUB_TOKEN repository secrets, which
apache/skywalking already has but this repository does not yet. Until they are added,
the release path will fail at login and the fallback release.sh docker x.y.z is needed.

The three third-party actions are pinned to the same reviewed SHAs already used in
apache/skywalking, so they are on the ASF allow-list.

---

Testing

• bash -n tools/releasing/release.sh passes; workflow YAML parses.
• resolve_version exercised from a branch cut off main, where git describe returns the broken v3.2.6:

Input	Result
(none)	9.7.0
9.7.0 / v9.7.0	9.7.0
RELEASE_VERSION=9.7.0	9.7.0
9.6.0	9.6.0 — older releases stay addressable
9.9.9	aborts, tag does not exist
abc	aborts, bad shape

• Milestone prompt exercised against the live GitHub API across correct / stale / nonexistent / non-numeric / blank inputs.
• Generated CHANGES.md is byte-identical to the hand-written 9.7.0 correction.
• Matrix expression renders 6 jobs on release, 5 on push.

🤖 Generated with Claude Code

[wu-sheng]

Pushed 02a563e after review feedback: the release path was rebuilding the agent rather than shipping the artifact that was voted on.

The previous local cmd_docker extracted apache-skywalking-java-agent-x.y.z.tgz — the tarball that was signed, uploaded to dist, and voted on — and fed that directory to the Dockerfile as ARG DIST. Moving the push into Actions quietly dropped that property: build-tar ran make build, so the published image would have contained a recompile of the tag rather than the approved bits.

Now build-tar is skipped on release events, and the tarball is downloaded from the Apache distribution area and verified before it can enter an image:

curl -fsSL -O "${BASE}/${TARBALL}"        # dist/release/skywalking/java-agent/x.y.z
curl -fsSL -O "${BASE}/${TARBALL}.asc"
curl -fsSL -O "${BASE}/${TARBALL}.sha512"

sha512sum -c "${TARBALL}.sha512"
curl -fsSL https://downloads.apache.org/skywalking/KEYS | gpg --import
gpg --verify "${TARBALL}.asc" "${TARBALL}"

sha512 rules out a truncated download; the signature check rules out anything the release manager did not sign. promote does the svn mv from dist/dev to dist/release immediately before the GitHub Release that triggers the workflow, so the file is in place when the job runs.

build-docker needed always() in its condition, since a skipped build-tar would otherwise skip it too. Development images are unchanged and still come from the artifact build-tar uploads.

Verified against the real 9.7.0 artifact:

apache-skywalking-java-agent-9.7.0.tgz: OK
gpg:                using RSA key D360AB2AB20B28403270E2CBE8608938DB25E06B
gpg: Good signature from "Sheng Wu <wusheng@apache.org>"
top-level: skywalking-agent/

All three dist URLs return HTTP 200 and the KEYS file carries 29 public keys.