Repository navigation
gh release create: Add flag to prevent a release if tag does not exist #6566
Description
Activity
Thanks for the suggestion. I'm not sure if this should be a separate issue, though. If we allow tag names for
--targetper #5855, then you should be able to achieve what you want with:gh release create v1.2.3 --target=v1.2.3Or did you have another idea for this feature in mind?
The workaround for you right now is to use the API to check if the tag already exists:
gh api --silent "repos/:owner/:repo/git/refs/tags/v1.2.3" && gh release create v1.2.3 --notes ""
- addedmore-info-neededMore info needed from user/contributorMore info needed from user/contributorand removedneeds-triageneeds to be reviewedneeds to be reviewed
on Nov 7, 2022 @mislav this feature request is slightly different. Instead of creating a release from an existing tag name using
--target, don't use that flag and only create a release if the required parameter[<tag>]represents an existing tag. That ability shouldn't be blocked by platform limitations.Instead of creating a release from an existing tag name using
--target, don't use that flag and only create a release if the required parameter[<tag>]represents an existing tag.Well, if
--target(a platform feature) was allowed to point to a tag, then you could achieve what you want with:gh release create v1.2.3 --target=v1.2.3 #=> (errors out if "v1.2.3" tag does not exist)I've proposed this approach because it should solve both this use-case and the use-case proposed in the thread you've linked (explicitly referencing tag names using
--target).That ability shouldn't be blocked by platform limitations.
You're right that the CLI should be able to implement what you're asking without relying on new platform features being shipped. We could check for the existence of remote tags by querying the GitHub API for git tags.
- addeddiscussFeature changes that require discussion primarily among the GitHub CLI teamFeature changes that require discussion primarily among the GitHub CLI teamand removedmore-info-neededMore info needed from user/contributorMore info needed from user/contributor
on Nov 14, 2022 We discussed this and agreed that a flag such as
gh release create <tag> --verify-tagwould be something we could implement in the gh client. We chose that name because--fail-on-missing-tagis a bit long, even if it's more accurate.The implementation would then be: if the flag is set, query
<tag>among repository tags via the GitHub API before creating the release, and abort the command if the tag was not found.@victorlin Does that sound good?
- addedhelp wantedContributions welcomeContributions welcomeand removeddiscussFeature changes that require discussion primarily among the GitHub CLI teamFeature changes that require discussion primarily among the GitHub CLI team
on Nov 14, 2022 @mislav that sounds great, thanks for the attention on this!
- added a commit that references this issue
on Nov 16, 2022
Originally from #5855 (comment).
Describe the feature or problem you’d like to solve
I want to create a release only if the tag exists (do not want auto tag creation with
gh release create <tag>).The docs currently say:
However, using
--targetis not a solution because I simply don't want to create a release in this case, not release from another commit ID.Proposed solution
Add a flag such as
--no-auto-tag/--fail-on-missing-tagwhich overrides the default behavior of creating the tag if it doesn't exist.