fix: handle merged PR titles in release workflow#46
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe release workflow now adds a manual ChangesRelease workflow updates
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5 | ❌ 1❌ Failed checks (1 warning)
✅ 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.
Pull request overview
Fixes the release workflow which broke when PR #45 was squash-merged, because GitHub appended (#45) to the commit title and the strict regex no longer matched. The workflow now strips a trailing (#<number>) suffix before validating against the SemVer release-title regex.
Changes:
- Strip GitHub merge/squash
(#<number>)suffix from the commit title before validation. - Preserve existing strict SemVer validation of the release title.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Release failed after #45 merged because the push commit message became
feat: release v0.1.0 (#45), while the workflow only accepted an exactfeat: release vX.Y.Z[-prerelease]title.This keeps the strict SemVer validation, but first strips the GitHub merge/squash
(#number)suffix when present. It also adds a manualworkflow_dispatchinput so the release can be rerun after this workflow fix lands, without touching the rockspec again.I verified these cases locally:
Invalid suffixes and unsafe version strings are still rejected. After this is merged, rerun the release with:
Summary by CodeRabbit
New Features
Chores