ci: Fail a release whose tag doesn't match the pom version - #142
Merged
Merged
Conversation
The first v2.4.0 run built the pom's 2.3.0. Signing was also broken, so nothing shipped. Had it worked, the v2.4.0 code would have gone to Central as 2.3.0, and Central releases can't be deleted. The check only runs on release events, so a manual run still publishes whatever version the pom has. A leading v on the tag is optional. Same step as mailerlite/mailerlite-java#18. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why?
The first v2.4.0 publish run built the pom's version, 2.3.0, because the tag was cut before the version bump. Signing was also broken, so nothing shipped. Had it worked, the v2.4.0 code would have gone to Maven Central as 2.3.0, and Central releases can't be deleted. This check stops that kind of run before anything is built.
Changes
publish.yaml: a new step beforePublish to Apache Maven Centralreads the pom version withmvn help:evaluateand fails the job if the release tag doesn't match. A leadingvon the tag is optional:v2.5.0and2.5.0both match2.5.0. The step only runs onreleaseevents, so a manual run behaves as before. It's the same step as in Fix Maven Central publishing and sync build with mailersend-java mailerlite/mailerlite-java#18.Risks
Low risk. The comparison was tested locally with matching and mismatched tag/version pairs, but the
mvn help:evaluateline first runs on the next release. If it misbehaves, the job fails beforemvn deploy, so nothing gets uploaded. Fix it and re-run.Performance impact
One extra Maven call per release, a few seconds.
Security impact
No security impact. The tag is read from the
GITHUB_REF_NAMEenvironment variable rather than through${{ }}interpolation, so a tag name can't inject shell commands.How to QA
There's nothing to QA before the next release. The Build check on this PR doesn't run this workflow. On the next release, check that
Check release tag matches pom versionpassed in theMaven Publishrun beforePublish to Apache Maven Central.SDK code and tests are unchanged and don't need QA.
How to release
Merge. The check applies from the next GitHub release, so bump the pom version before publishing it.
Rollback strategy
Screenshots, recordings
N/A
I used AI to generate parts of this PR
Yes
🤖 Generated with Claude Code