Repository navigation
ci(release): make the manual trigger work and guard the version - #4
Merged
codeminute-the-dev merged 1 commit intoAug 23, 2026
Merged
Conversation
workflow_dispatch declared a `version` input that no job ever read. Every field came from github.ref_name, so a manual run from master would have published a release named "RawView master" and tried to create a `master` tag. The button was unusable. A `version` job now resolves the tag once for both triggers: a tag push carries it, a manual run passes it in (with or without the leading v) and action-gh-release creates the tag at that commit via tag_name. The same job refuses to build when the tag does not match pyproject.toml. Every packaging script derives its filenames from there - build-deb.sh:30, build-appimage.sh:28, build-rpm.sh, scripts/build-msi.ps1:16 - so tagging v1.3.1 while pyproject.toml still said 1.3.0 would have published rawview_1.3.0_amd64.deb and RawView-1.3.0.msi inside a release called v1.3.1. It now fails in seconds, before the two runners spend ~15 minutes downloading Ghidra and building packages. Prerelease is derived from the resolved tag rather than the raw ref, so a v1.4.0-rc.1 tag is still flagged prerelease.
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
2 participants
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.
Makes
release.ymlreleasable from the GitHub UI (or by me) without a terminal, and stops a version mismatch from shipping.The dispatch button didn't work
workflow_dispatchdeclares aversioninput, but no job ever reads it — every field came fromgithub.ref_name. A manual run frommasterwould have published a release named "RawView master" and tried to create amastertag.A new
versionjob resolves the tag once for both triggers:1.3.1orv1.3.1, both fine) andaction-gh-releasecreates the tag at that commit viatag_nameprereleasenow derives from the resolved tag rather than the raw ref, sov1.4.0-rc.1is still flagged correctly.Version guard
The same job refuses to build when the tag doesn't match
pyproject.toml. Every packaging script derives its filenames from there —build-deb.sh:30,build-appimage.sh:28,build-rpm.sh,scripts/build-msi.ps1:16. Taggingv1.3.1whilepyproject.tomlstill said1.3.0would publishrawview_1.3.0_amd64.debandRawView-1.3.0.msiinside a release called v1.3.1.It now fails in seconds, before the two runners spend ~15 minutes each downloading Ghidra 12.0.4 and building packages.
Verified
I extracted the resolve step's shell and ran it against the real
pyproject.toml(1.3.1):1.3.1v1.3.1, prerelease=falsev1.3.1v1.3.1v1.3.1v1.3.1v1.4.0-rc.11.3.0master1.3YAML parses and the job graph is
version → {linux, windows} → release.After this merges
v1.3.1 can be released without a terminal: Actions → Release → Run workflow → version
1.3.1. Or tell me and I'll trigger it.Generated by Claude Code