ci: Add Maven Central release workflow; DRY and harden snapshot deploy

[jeffjensen]

What

• Release workflow (release.yml) — triggers on v* tags (maven-release-plugin), runs in a release environment, and deploys -Prelease (GPG-signed) to Maven Central. Adds GPG + Central-credential inputs to the jdk-setup composite action so the release job can authenticate and sign. Includes README + Releasing-guide doc updates.
• DRY deploy-snapshot.yml — collapse the redundant jdk-setup + setup-java pair into a single jdk-setup call.
• Harden deploy-snapshot.yml — permissions: contents: read, a snapshot-deploy concurrency group, pinned ref: head_sha checkout, and persist-credentials: false.

source:jar-no-fork is intentionally omitted — packaging: maven-archetype has no Java sources and Central doesn't require a sources jar for archetypes.

Before the first release

Add repo secrets GPG_PRIVATE_KEY and GPG_PASSPHRASE (the CENTRAL_* pair already exists for snapshot deploys) and create a release environment. Full setup is in the Releasing guide updated in this PR.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added a new release workflow to publish tagged builds to Maven Central with signed artifacts.
  • Updated build setup to support optional publishing credentials and signing keys when needed.

• Bug Fixes

  • Improved snapshot deploy behavior by checking out the correct commit and avoiding credential persistence.

• Documentation

  • Updated CI/CD and release documentation to match the new GitHub-based release process and required secrets.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a new release.yml GitHub Actions workflow that publishes GPG-signed artifacts to Maven Central on v* tag pushes. The shared jdk-setup composite action is extended with conditional GPG and Maven Central credential inputs. The deploy-snapshot.yml workflow is hardened with permissions, concurrency, and credential settings. Documentation in README.adoc and releasing.adoc is updated to reflect the CI-driven release process.

Changes

Maven Central Release CI Pipeline

Layer / File(s)	Summary
Conditional GPG/Central credentials in jdk-setup action .github/actions/jdk-setup/action.yml	Adds optional server-id, server-username, server-password, gpg-private-key, and gpg-passphrase inputs. Splits the single setup step into two conditional branches: basic Temurin 21 + Maven cache when server-id is empty, and a full credentials-wired actions/setup-java@v5 step when server-id is set.
New release.yml workflow .github/workflows/release.yml	Defines a workflow triggered by v* tag pushes with contents: read permissions, release-deploy concurrency (no cancel), release environment, and a job that checks out without persisted credentials, invokes jdk-setup with Central and GPG secrets, and runs ./mvnw deploy -Prelease -DskipTests -Darchetype.test.skip=true.
deploy-snapshot.yml hardening .github/workflows/deploy-snapshot.yml	Adds contents: read permission, snapshot-deploy concurrency group with cancel-in-progress: false, explicit head_sha checkout with persist-credentials: false, and removes the now-redundant actions/setup-java@v5 step.
README and releasing guide updates README.adoc, src/site/asciidoc/releasing.adoc	README adds a fourth workflow entry with trigger, deploy command, environment, and GPG secrets table. releasing.adoc is rewritten to describe the CI/secrets-driven flow, GitHub environment approval gate, failure/abort procedures, fixed outputTimestamp model, and updated post-release checklist.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐇 A tag is pushed, the pipeline wakes,
GPG keys sign what Maven makes.
Credentials flow through secrets bright,
Central receives the artifacts right.
Four workflows now, the rabbit cheers—
Release without local fears! 🎉

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main changes: a Maven Central release workflow plus DRY and hardened snapshot deploys.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/release-to-maven-central

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/site/asciidoc/releasing.adoc (1)

146-152: 🎯 Functional Correctness | 🟠 Major | ⚖️ Poor tradeoff

Rewrite the reproducible-builds explanation to match the fixed-outputTimestamp model.

The current text claims release:prepare updates the timestamp automatically, which contradicts the PR's "fixed outputTimestamp model" and the literal value in pom.xml. The property should be described as holding a fixed value that is only changed manually when needed.

Suggested rewrite:

-`release:prepare` updates `project.build.outputTimestamp` to the current UTC instant
-automatically before committing the release POM, so released artifacts carry the exact
-timestamp of the release commit.

-Between releases the property holds a fixed timestamp — the last release's instant, or the
-initial project creation date before the first release — ensuring that `./mvnw verify` is
-reproducible regardless of when the build runs.
+`project.build.outputTimestamp` is set to a fixed timestamp in `pom.xml`
+(the initial project creation date or the last manually updated value).
+This ensures that `./mvnw verify` produces byte-for-byte reproducible artifacts
+regardless of when the build runs.
+The timestamp is only changed manually when a new reproducibility baseline is desired.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/site/asciidoc/releasing.adoc` around lines 146 - 152, Rewrite the
reproducible-builds section in releasing.adoc to describe the fixed
outputTimestamp model instead of saying release:prepare updates it
automatically. Update the explanation around project.build.outputTimestamp to
say it stays at a fixed value between releases, is only changed manually when
needed, and that release:prepare uses the existing timestamp value rather than
mutating it. Use the surrounding release preparation and
verify/reproducible-builds text to keep the wording consistent.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/site/asciidoc/releasing.adoc`:
- Around line 67-69: Remove the claim in the release documentation that
`release:prepare` updates `project.build.outputTimestamp`; in the
`releasing.adoc` description of `release:prepare`, delete the parenthetical
about updating the timestamp and keep the rest of the workflow description
unchanged. Reference the `release:prepare` paragraph in `releasing.adoc` so the
fixed `outputTimestamp` model remains accurately documented.

---

Outside diff comments:
In `@src/site/asciidoc/releasing.adoc`:
- Around line 146-152: Rewrite the reproducible-builds section in releasing.adoc
to describe the fixed outputTimestamp model instead of saying release:prepare
updates it automatically. Update the explanation around
project.build.outputTimestamp to say it stays at a fixed value between releases,
is only changed manually when needed, and that release:prepare uses the existing
timestamp value rather than mutating it. Use the surrounding release preparation
and verify/reproducible-builds text to keep the wording consistent.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 7634b0f0-be8f-40cd-904c-0f13ded102fa

📥 Commits

Reviewing files that changed from the base of the PR and between 5e54554 and f7b9f2f.

📒 Files selected for processing (5)

• .github/actions/jdk-setup/action.yml
• .github/workflows/deploy-snapshot.yml
• .github/workflows/release.yml
• README.adoc
• src/site/asciidoc/releasing.adoc