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

• Chores
  • Improved release automation to use the project’s official version number when publishing releases.
• Bug Fixes
  • Added a validation check to prevent releases from being published if the tag does not match the expected version.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ebea9c0f-49bc-4f57-affc-07b31cb13b1b

📥 Commits

Reviewing files that changed from the base of the PR and between dcfd17f and 28f6649.

📒 Files selected for processing (1)

• .github/workflows/release.yml

---

📝 Walkthrough

Walkthrough

The release workflow adds a Verify tag matches project version step that reads project.version via Maven, asserts the pushed tag equals v${project.version}, and exports the resolved version as a job output. The downstream github-release job then uses that output as the GitHub Release title instead of stripping the leading v from the tag name.

Changes

Tag Validation and Version Propagation

Layer / File(s)	Summary
Tag verification step and job output declaration .github/workflows/release.yml	The release job declares a version output and adds the resolve step, which evaluates project.version, aborts on a tag mismatch, and writes the version to $GITHUB_OUTPUT.
github-release consumes resolved version .github/workflows/release.yml	VERSION is sourced from needs.release.outputs.version and passed as --title "$VERSION" to gh release create, replacing the previous ${TAG#v} derivation.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5 minutes

Possibly related PRs

• database-audits/core#3: Introduces the original tag-triggered release workflow in .github/workflows/release.yml that this PR extends with strict tag-vs-project.version validation.

🚥 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 matches the main change: adding a release-tag guard to prevent 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.}