[venkata-kishore]

Changes the release order to:

1. build and sign once;
2. publish to GitHub Packages;
3. create the tag vX.Y.Z and its GitHub release;
4. upload to Maven Central.

Until now Central came first, then GitHub Packages, and the tag last. With the new order, a release that Central delays or rejects, for example once the organization is over Central's monthly publishing limits, is still tagged, released on GitHub and available from GitHub Packages. Central catches up later.

How

• One Maven run does verify, deploy:deploy to GitHub Packages, and central-publishing-maven-plugin:publish -DskipUpload=true. That last goal only builds Central's bundle from the same signed files. Maven stops at the first failure, so a failed GitHub upload ends the release before any tag or Central step.
• The tag and GitHub release are created with gh release create, as before.
• The Central upload sends that bundle through Central's Publisher API (POST /api/v1/publisher/upload?publishingType=AUTOMATIC). It then polls /api/v1/publisher/status every 10 seconds:
  • It stops once the state is VALIDATED, PUBLISHING or PUBLISHED. Central finishes copying to repo1 on its own, so no runner sits waiting for that.
  • It fails on FAILED and prints Central's errors. It also fails if Central refuses the upload, printing the response, or if nothing is validated within an hour.
• Fewer secrets in the build. The Central token is now only in the upload step's environment; the Maven build no longer sees it. -DwaitMaxTime is gone because Maven no longer uploads to Central.

Re-runs

• The tag check now accepts a tag that already points at the commit being released and skips the tag step. A tag on a different commit is still an error.
• To finish a release whose Central step failed, either:
  • re-run the failed job, which builds the same commit even if prime has moved on; or
  • run the release workflow by hand on the tag vX.Y.Z. Manual runs on refs/tags/v* are now allowed, and the tag must match the pom version.
• Either way, GitHub Packages and the tag are skipped, and the version is rebuilt, signed and uploaded to Central. Central's copy then has fresh signatures. They are still valid, but they are not byte-identical to the GitHub Packages copy from the first run.

Checked

• Maven part: checked locally on a throwaway release-version copy of oss-parent's POM.
  • The goals run in the order above.
  • With -DskipUpload=true the bundle lands at target/central-publishing/central-bundle.zip, the path the upload step reads.
  • A failing GitHub step stops the build before any bundle exists.
• Central API calls: the upload and status endpoints exist and answer 401 without credentials.
• Upload step script: run against a local stand-in for the API.
  • Upload accepted, then validated: the job passes.
  • Validation FAILED: Central's errors are printed and the job fails.
  • Upload refused with a 400: the message is printed and the job fails.
  • The request carries the bundle multipart field, publishingType=AUTOMATIC and name=<artifact> <version>.
• Tag lookup: for both annotated and lightweight tags, it resolves to the tagged commit.
• actionlint (with shellcheck) reports only the known runner label and the intentional word splitting of Maven arguments.

Untested: a real upload to Central. It happens for the first time on the next release. If it fails, the tag and the GitHub Packages copy already exist, so it is fixed by correcting the workflow and re-running the failed job.