Repository navigation
ci: fail fast when the Windows pipeline would publish a non-release tag - #215
Merged
Merged
Conversation
GitHubRelease@1 (action: edit) creates the tag when no release exists for it. ReleaseTag defaulted to `main`, so publishing without overriding it created a lightweight `main` tag that shadows the `main` branch: `git pull origin main` fetched the stale tag and silently did nothing. - Default ReleaseTag to `unreleased`; outside publishing it only names the artifacts. - When PublishToGitHub is enabled, validate ReleaseTag as v<major>.<minor>.<patch>[-pre] in the first step of both jobs, before any build or signing work. - Document the requirement in CONTRIBUTING.md. The stray remote tag itself (0b3b528, the same commit as v0.1.11) was deleted separately. Fixes #213 Co-authored-by: Copilot App <[email protected]>
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
Both publishing paths have consistent early validation and no blocking issues were identified, though execution in Azure DevOps remains unverified.
No open issues 🎉
What changed in this PR
Prevents the Windows signing pipeline from accidentally publishing a branch-named tag, addressing the cause suspected in #213.
Changes:
- Changes the default
ReleaseTagfrommaintounreleased. - Adds publishing-only release-tag validation before build and signing work in both architecture jobs.
- Documents the publishing requirement and branch-shadowing risk.
| File | Description |
|---|---|
| CONTRIBUTING.md | Documents the required release-tag format when publishing Windows artifacts. |
| .github/workflows/sign-and-release.yml | Sets a non-branch default and adds early validation to both publishing jobs. |
Review effort: Balanced
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
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.
Fixes #213
What happened
refs/tags/main(lightweight, on0b3b528, the same commit asv0.1.11) shadowedrefs/heads/main, sogit pull origin mainfetched the stale tag and did nothing.Already done (outside this PR)
git push --force-with-lease=refs/tags/main:0b3b528f5a1961a4beaeff106cd9217199788375 origin :refs/tags/main.git fetch origin mainnow resolves to the branch. No release, workflow or script used that tag, andv0.1.11is untouched.git push origin 0b3b528f5a1961a4beaeff106cd9217199788375:refs/tags/main.Likely cause and prevention (this PR)
sign-and-release.yml(the Azure DevOps OneBranch signing pipeline) defaultedReleaseTagtomain, and itsGitHubRelease@1steps useaction: edit, which creates the tag when no release exists for it. A publishing run that kept the default would create exactly this tag. That fits the evidence, but I can't confirm it from here, since the pipeline runs in ADO.ReleaseTagnow defaults tounreleased. Outside publishing it only names the artifacts.PublishToGitHubenabled, the first step of both jobs rejects anything other thanv<major>.<minor>.<patch>[-pre], before any build or signing work.CONTRIBUTING.mdnotes the requirement next to the Windows signing paragraph.Verification
git ls-remote origin mainandgit fetch --dry-run origin main.PublishToGitHubexpansion: the guard is the first step of both jobs only when publishing, and the publish steps are unchanged.v1.2.4andv1.3.0-rc.1, and rejectsmain,v2-dev,1.2.4,V1.2.4,refs/tags/v1.2.4and the empty string.PublishToGitHubon and a bad tag would confirm the failure message.Follow-ups (not in this PR)
v*would block this class of mistake at the source. It needs repo admin; all current rulesets target branches only.git tag -d main, thengit pull origin main.