ci: Guard release tag against project version mismatch

[jeffjensen]

What

Closes a gap where a mistyped or mis-placed release tag could publish one artifact version to Maven Central while the GitHub Release announced a different one.

• The deploy publishes the POM version, but the GitHub Release was titled from the tag suffix — two independent derivations that can drift apart.
• Adds a pre-deploy guard that resolves project.version from the POM (the source of truth for what is deployed) and fails the release unless the tag encodes exactly that version.
• Titles the GitHub Release from the resolved version (passed out of the deploy job as a job output), so the published artifact and the Release can no longer disagree.

Because github-release depends on release, the single guard protects both the deploy and the Release creation. Maven Central artifacts are immutable, so failing closed before deploy is the safe behavior.

🤖 Generated with Claude Code

https://claude.ai/code/session_0133BgD2ro4ZJh1TaXHrZSff

Summary by CodeRabbit

• Bug Fixes
  • Added validation to ensure release tags match the project’s version before publishing.
  • GitHub Releases now use the resolved project version for the release title, reducing version mismatches.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 256a67ca-5671-47a0-aac5-1bcb21f40535

📥 Commits

Reviewing files that changed from the base of the PR and between de3fe85 and 1fdfa2c.

📒 Files selected for processing (1)

• .github/workflows/release.yml

---

📝 Walkthrough

Walkthrough

The release workflow gains a resolve step that reads project.version via Maven and verifies the pushed Git tag equals v${project.version}, failing on mismatch. The resolved version is surfaced as a job output and used to set the GitHub Release title, replacing the previous tag-derived title logic.

Changes

Release workflow: tag/version verification and title

Layer / File(s)	Summary
Version resolution, tag validation, and release title .github/workflows/release.yml	Declares version as a release job output; adds a resolve step that evaluates project.version via Maven, asserts the tag equals v${project.version}, and writes the version to GITHUB_OUTPUT; updates the github-release job to source VERSION from the job output and pass it as --title to gh release create.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• jeffjensen/java-service-archetype#8: Introduced and structured the same release.yml workflow that this PR extends with tag/version validation and release title logic.

Poem

🐇 A tag must match the version true,
Or Maven will shout "This won't do!"
We parse project.version with care,
Then craft the release title with flair.
No mismatched tags shall slip on through! 🎉

🚥 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 change: adding a CI guard to prevent release tag and project version mismatches.
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-version-guard

---

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.}