Repository navigation
gh release create: Allow tag names for --target #5855
Description
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>). Currently, this can be done by:
# Asserts that <tag> is an actual tag, not a branch name or other ref.
git rev-parse --verify "<tag>^{tag}" >/dev/null
# Translate from tag into commit for `gh release create --target`.
commit="$(git rev-parse --verify "<tag>^{commit}")"
gh release create <tag> --target "$commit"Proposed solution
This can be greatly simplified if gh release create --target accepts a tag name:
gh release create <tag> --target <tag>
Additional context
In #2133 (comment), @mislav thought this was already a feature (I would think so too!). However, I did some testing and this is not the case:
Run gh release create v0.1.0 --target v0.1.0
HTTP 422: Validation Failed (https://api.github.com/repos/victorlin/github-test/releases)
Release.target_commitish is invalid
Error: Process completed with exit code 1.
Run gh release create v0.1.0 --target refs/tags/v0.1.0
HTTP 422: Validation Failed (https://api.github.com/repos/victorlin/github-test/releases)
Release.target_commitish is invalid
Error: Process completed with exit code 1.
Activity
spenserblack commentedon Jun 27, 2022
Related? #4357
I would also think it's already a feature based on the issue's fix.
Edit: IIRC the fix was to enforce that a local tag is pushed with an explicit warning that it only exists locally. Perhaps
--target <tag>should do the same?mislav commentedon Jul 11, 2022
Thanks for the context everyone. I've just gone and looked at the platform code and it seems like
--targetonly works with branch names and commit SHAs, but not with tag names. I'm not sure if the exclusion of tag names was intentional (the original logic is 9 years old and remained intact all this time), but I'm guessing that the authors of the original logic did not anticipate this use-case.Will file this as a platform issue for now. For now, the only way to ensure that
gh release createwill never automatically create the git tag is to first ensure that the git tag is pushed.victorlin commentedon Jul 11, 2022
I see it calls the Releases API, where
--targetmaps totarget_commitish:@mislav thanks for pointing out that this is a platform issue.
mislav commentedon Jul 11, 2022
Note that CLI documentation for
release createalso says:So there is no promise anywhere that tag names are valid input. In fact, they never worked for this API endpoint. I didn't spot this before and I'm sorry I misled you in the other thread. I'm currently asking internally whether there is a possibility that tag names get included in the commitish lookup.
spenserblack commentedon Jul 11, 2022
I'm just guessing, but maybe
target_commitishcan't be a tag for/repos/{owner}/{repo}/releasesbecausetag_nameis already used for tags? In fact, the docs sayIf a target can be a tag then it raises the question "what happens when the target tag and tag name don't match?" E.g.
gh repo create v1.0.0 --target v2.0.0victorlin commentedon Jul 11, 2022
@spenserblack I see, that's valid... in that case, another feature request that would solve the original problem in the issue description would be to have a flag like
--no-auto-tag/--fail-on-invalid-tagwhich overrides the default behavior of creating the tag if it doesn't exist.michaelmdresser commentedon Nov 3, 2022
I am also interested in having a flag like @victorlin is suggesting to ensure that
gh release createdoes not create a tag.victorlin commentedon Nov 4, 2022
@michaelmdresser I created a separate issue #6566 for that feature. I think it is based on CLI logic and shouldn't be blocked due to platform issues. Please give thumbs up there!
feat(release): Add configurable release_conf.yml support