fix: a moved tag left its release as an unpublished draft - #189
Merged
Conversation
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.
Found while verifying a retag on a sibling project, whose release job is a copy of this one. Deleting a tag in order to move it reverts its GitHub release to a draft.
gh release viewsucceeds on a draft, so theif ! gh release view "$TAG"guard treats it as already released, skips creation, and uploads the rebuilt apk and SBOM into a release that stays invisible. Nothing fails, and the feed keeps serving the previous version becausegh release listdoes not return drafts.gh release edit "$TAG" --draft=falseafter the uploads is the documented way to publish a draft, and it is a no-op on a release that was never one. The prerelease flag is untouched, so an rc tag stays a prerelease and stays out of the feed.This has not bitten a uapi release. It is going in here because the retag procedure in the release process is the trigger, the job is identical, and the failure is silent by construction.
Wire surface: none. Release plumbing only, no runtime code and no schema change, so no semver impact.
Verified against a real device, or only CI? Neither, and it does not need either. The behaviour was observed on a real GitHub release in the sibling project: a release left as
isDraft=trueafter a tag deletion, holding a rebuilt asset, while the feed served the older version. The fix is the documented inverse of that state.LuCI checked? Not applicable, this is release tooling.