ci(release): Tag-triggered Maven Central release workflow#4
Conversation
Extend the composite (previously JDK + cache only) with optional server-id, credential, and gpg inputs, matching the core and spring-boot copies, so the release workflow can sign and deploy through it. Backward compatible: callers without inputs still get the plain JDK setup. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013DKrZ3wSe6H5HXPzg8iWC6
Commit release.yml so a pushed v* tag (created by release:prepare) deploys -Prelease (-N) to Maven Central. Use the jdk-setup composite and add the release-deploy concurrency group, the release environment approval gate, contents: read permissions, and checkout v7. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013DKrZ3wSe6H5HXPzg8iWC6
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughTwo files are modified and one new workflow is added to support automated Maven Central releases with improved credential security. The ChangesMaven Central Release Pipeline
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 @.github/actions/jdk-setup/action.yml:
- Line 29: The `actions/setup-java` action in the jdk-setup composite action
uses a mutable major-version tag (v5) which can change unexpectedly and poses a
security risk in the release path. Replace the `@v5` tag with an immutable full
commit SHA for the exact version of `actions/setup-java` that should be used,
ensuring reproducibility and preventing accidental updates to different versions
during release workflows.
In @.github/workflows/release.yml:
- Line 24: The checkout action at line 24 uses a mutable tag (v7) which poses a
security risk in a release workflow that handles sensitive secrets like
CENTRAL_USERNAME, CENTRAL_TOKEN, and GPG_PASSPHRASE. Replace the
`actions/checkout@v7` reference with a pin to a specific commit SHA instead of
the mutable tag, and add the `persist-credentials: false` option to disable
credential persistence since this workflow does not perform any git operations
after the checkout step.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: b5995d98-89eb-4394-a594-b58fd46ebb12
📒 Files selected for processing (2)
.github/actions/jdk-setup/action.yml.github/workflows/release.yml
The release job only deploys (no git push-back), so the GITHUB_TOKEN that checkout persists in .git/config is unnecessary attack surface in a workflow handling GPG and Maven Central secrets. Set persist-credentials: false. Addresses the CodeRabbit/zizmor finding; SHA-pinning is deferred to a separate project-wide policy. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013DKrZ3wSe6H5HXPzg8iWC6
deploy-snapshot also handles Maven Central credentials and never pushes back to git, so drop the persisted GITHUB_TOKEN. Same hardening as the release workflow. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013DKrZ3wSe6H5HXPzg8iWC6
Commits and standardizes
release.ymlso releases publish from CI instead of a localrelease:perform.Flow
mvn release:prepare -N(local) bumps the version, tagsv<version>, and auto-pushes (pushChangesdefault). The tag triggersrelease.yml, which waits for approval on thereleaseenvironment, then runsdeploy -Prelease -N(GPG-signed, auto-published to Central).Changes
jdk-setupcomposite — extended with the optional Central/GPG inputs the other repos' copies already have (was JDK + cache only), so the release workflow can sign/deploy through it. Backward compatible.release.yml— committed (was untracked); now uses the composite and addspermissions: contents: read,release-deployconcurrency,environment: release(approval gate), andcheckout@v7. Keeps-N(single pom).No
releasing.adoc— parent has no Maven site. Its release steps match core/boot (minus Docker; uses-N).Prerequisites before first use
CENTRAL_USERNAME,CENTRAL_TOKEN,GPG_PRIVATE_KEY,GPG_PASSPHRASE.releaseenvironment with a required reviewer (the approval gate).🤖 Generated with Claude Code
https://claude.ai/code/session_013DKrZ3wSe6H5HXPzg8iWC6
Summary by CodeRabbit