ci: release the platform and the Java SDK together from a vX.Y.Z release

[JosteinGj]

Why

A platform release delivered nothing. #145 set up release branches (release/vX.Y), but no workflow reacted to a release. No artifacts were built or attached, and every app was hard-coded at 0.0.1-SNAPSHOT, so the console's About dialog, which is also its AGPL source offer, could not say which release was running. Operators install from source (git clone + ./scripts/up.sh --build), or for production follow systemd/README.md, which builds the jars with ./gradlew bootJar and installs one per service.

The SDK had a release pipeline of its own (#148), on its own version and also on vX.Y.Z tags. Two release lines on the same tags would collide: a platform release would start an SDK publish.

The decision is to couple them for now: one version, one tag, one release for the platform and the Java SDK, like the Rust SDK already follows the platform's version line. Splitting later means giving the SDK its own version property and tag prefix again.

This supersedes #151, which separated the two.

What changes

One version (4c611bcd)

• version=1.0.0-SNAPSHOT in the root gradle.properties, which Gradle applies to every module. -Pversion=X.Y.Z overrides it.
• It replaces the six apps' version = '0.0.1-SNAPSHOT' and the SDK's apiModelVersion/javaSdkVersion. centralBundle names its zip from it.
• The About dialog now reports the real version.
• deploy/app/Dockerfile copied ${MODULE}-0.0.1-SNAPSHOT.jar by name. It now copies each module's boot jar (skipping -plain) to a fixed name in the build stage, so the runtime stage need not know the version. Tested by building the datahub-cleanup image with podman.
• The Pulsar filter's NAR keeps its unversioned local name, datahub-pulsar-filter.nar, because its README and broker setups load it by path. The release copy carries the version.
• datahub-e2e/README.md globs the jar instead of naming the version.

The release workflow (878b5bec)
.github/workflows/java-sdk-release.yml becomes release.yml. A vX.Y.Z GitHub Release runs:

Job	What it does
versions	The tag is vX.Y.Z, equals version, and its commit is on release/vX.Y
build	./gradlew build (build.yml does not run on releases)
platform	Boot jars for api, console, stateless-consumer, analysis and cleanup (the services systemd/ runs), plus datahub-pulsar-filter-X.Y.Z.nar and a SHA256SUMS
sdk	Verifies the locally signed SDK bundle attached to the release, unchanged from #148
publish-sdk	In the release environment, after approval: uploads the verified bundle to Maven Central
attach-platform	After the SDK is on Central: attests build provenance (actions/attest, as the Rust repo does for its wheels) and attaches the jars, NAR and SHA256SUMS to the release

The platform jars are attached last, so a release shows its jars only once all of it went out. If Central fails, re-running the failed jobs finishes the release.

systemd/README.md now installs the jars from the release, checked against SHA256SUMS, with building from a checkout of the tag as the alternative.

On a pull request that touches a build file, the version or the release machinery, the workflow rehearses everything except the upload and the attaching.

To release X.Y.Z (also in AGENTS.md):

# on release/vX.Y, with version=X.Y.Z in gradle.properties
./gradlew centralBundle -PsigningUseGpgCommand=true
gh release create vX.Y.Z --target release/vX.Y build/central/datahub-central-X.Y.Z.zip

Decisions to confirm

• The next version is 1.0.0, the platform's planned first release (ci: run checks on release/vX.Y branches #145). Coupled, the SDK's first Maven Central release is therefore 1.0.0, not the 0.3.0 it was heading for. That is a one-line change in gradle.properties if you prefer otherwise.
• Platform jars are not GPG-signed. They carry SHA256SUMS and a GitHub build-provenance attestation (gh attestation verify <file> --repo IntelliStream-DataHub/datahub-platform), which ties each file to this workflow and the tagged commit without anyone holding a key. Signing them locally like the SDK is possible, but adds a step to every release.

Needed in the GitHub settings

The release environment is set up for #151's sdk-v* tags. For this scheme:

• Change the tag rule back to v*.
• Add a required reviewer. There is none, so publish-sdk would upload with no approval.
• Turn off admin bypass.
• Restore the real CENTRAL_TOKEN_PASSWORD after testing.

Also recommended: a branch ruleset on release/* (still open from #145), and a tag ruleset restricting who may create v* tags.

Docs

• datahub-docs (operators): yes. docs/administration/installing.mdx should say a production install takes the jars from the release matching the version, as systemd/README.md now does. Pinning the evaluation stack to a tag (git clone --branch vX.Y.Z) would also make releases meaningful there.
• datahub-sdk-docs: after the first release, the install snippets should point at ai.intellistream:datahub-sdk:1.0.0.

Verification

• ./gradlew build is green, and every module reports version: 1.0.0-SNAPSHOT.
• The platform job's script was run locally as written: it produced the five jars, the versioned NAR and SHA256SUMS.
• The sdk job's rehearsal was simulated locally from the YAML, and the verifier passes.
• The versions check was run in a scratch repository: v1.0.0 on release/v1.0 passes, while a tag that disagrees with version, an sdk-v tag, and a commit not on the release branch are refused.
• The Dockerfile was tested by building the datahub-cleanup image.
• Not yet exercised: a real release event, the provenance attestation and the attaching step, and signing with the release manager's real key.

🤖 Generated with Claude Code