fix: select latest release tag for Docker rebuild workflow#635
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes the Docker rebuild workflow so it rebuilds from the highest stable release tag in the repository instead of the nearest tag reachable from the checked-out branch. That aligns the workflow with the repository’s release process and avoids publishing an older version as latest.
Changes:
- Replaces
git describe --tags --abbrev=0with a tag query sorted by semantic version. - Filters the selected tag to stable
vX.Y.Zreleases only. - Fails the workflow explicitly when no matching release tag is found.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #635 +/- ##
=======================================
Coverage 80.99% 80.99%
=======================================
Files 162 162
Lines 12113 12113
=======================================
Hits 9810 9810
Misses 1806 1806
Partials 497 497
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
creativeprojects
left a comment
creativeprojects
left a comment
There was a problem hiding this comment.
This was indeed the first time I had to make a quick hot fix while the main branch wasn't clean 😢
Thanks for this PR 👍🏻
I'll kick off a weekly rebuild of the image after merging 😉
The latest Rebuild docker image workflow run tagged
v0.33.0aslateston Docker Hub instead ofv0.33.1.This happened because the workflow used
git describe --tags --abbrev=0, which selects the nearest tag reachable frommaster. In this case, thev0.33.1tag points to a commit outsidemaster, so the workflow fell back tov0.33.0.This PR fixes the workflow by selecting the highest stable release tag directly, regardless of which branch contains the tagged commit.