ci(build): do not run the release matrix for internal v0.0.0-* tags - #598
Merged
Conversation
`v0.0.0-*` is this repository's existing marker for a tag that is not a product version — a place to hang a binary needing a permanent public URL, the way `v0.0.0-stt-models` hosts the 360 MB Whisper model. `build.yml` triggers on `v*` with no further filter, so creating one runs the entire matrix — Windows, macOS x2, Linux, installers, notarisation — to publish an archive it was never asked to build. That has already happened once: there is a `build.yml` run against a `v0.0.0` tag in the history. The reason this matters now is #591: adopting a locally built ONNX Runtime means publishing it under such a tag, and doing that should not cost a full release build every time the pinned version moves. The other five release-triggered workflows do NOT need the same guard, which was checked rather than assumed: `aur-publish`, `bump-nix-package`, `publish-winget` and `update-homebrew-cask` all gate on `!github.event.release.prerelease`, and an internal release is marked as a prerelease — so none of them can push a bogus version to a package manager. `announce-release` has no such gate and would post to Discord; that is noise rather than a wrong publication, and whether an internal release deserves an announcement is a call for whoever owns the channel, so it is left alone here.
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe build workflow now ignores ChangesBuild trigger filtering
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to Internal marker tags no longer start the full release build matrix, avoiding unnecessary builds without changing prerelease build dispatch or release announcements. No current merge-blocking risk remains. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
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.
v0.0.0-*is this repository's existing marker for a tag that is not a product version — a place to hang a binary that needs a permanent public URL, the wayv0.0.0-stt-modelshosts the 360 MB Whisper model.build.ymltriggers onv*with no further filter, so creating one runs the entire release matrix — Windows, macOS ×2, Linux, installers, notarisation — to publish an archive it was never asked to build. That has already happened: there is abuild.ymlrun against av0.0.0tag in the history.It matters now because of #591: adopting a locally built ONNX Runtime means publishing it under such a tag, and that should not cost a full release build every time the pinned version moves.
The other five release-triggered workflows are fine, and that was checked
aur-publish!github.event.release.prerelease✓bump-nix-package!github.event.release.prerelease✓publish-winget!github.event.release.prerelease✓update-homebrew-cask!github.event.release.prerelease✓announce-releaseAn internal release is marked as a prerelease (as
v0.0.0-stt-modelsis), so none of the four package-manager publishers can be tricked into pushing a bogus version. That was the risk worth checking, and it is already covered.announce-releasehas no prerelease gate and would post to Discord. That is noise rather than a wrong publication, and whether an internal release deserves an announcement is a call for whoever owns that channel — so this PR leaves it alone rather than deciding.What a reviewer should push back on
!v0.0.0-*encodes a convention that lives only in one tag name and one release title. Ifv0.0.0-is not actually the intended marker for internal assets, this exclusion is wrong and something more explicit — adeps/prefix, or a tag-shape check inside the job — would be better.v0.0.0-*release as a full release, this PR does nothing to stop AUR and Homebrew from acting on it.Summary by CodeRabbit