Should `gh release create` push the local tag if it exists?

[spenserblack]

Describe the feature or problem you’d like to solve

When using gh release create with a tag that exists in the local repository but not in origin, it creates a new tag instead of pushing the local tag. This seemed like confusing behavior to me.

Proposed solution

If the tag name passed to gh release create already exists in the local repo, that tag should be pushed instead of a new tag with the same name being created for the release. This behavior might match the expected behavior.

Additional context

Of course, there is a workaround for this already: push the tag before using gh release create 😆
But, since other commands will push changes to the remote for you (like gh pr create), I was a bit surprised that gh release create didn't push the local tag.

[guerinoni]

I tried to create a local tag for my repo and use gh release create <that tag> and it works correctly... Maybe because I'm on HEAD?

[spenserblack]

🤔 When I found this I was on version 2.0.0. I'll upgrade and test this out.

[spenserblack]

No, looks like I'm still experiencing this issue. To clarify, what I'm doing is

git commit --allow-empty -m "new commit" # I do this to have a new commit to add a tag to
git tag -a v1.2.3 # annotated commit
gh release create v1.2.3
# select "no title"
# select "Write using git tag message as template"
# select "No"
# select "Publish release"

At this point, a new release is created with tag v1.2.3. However, this isn't the same tag, because it is missing the annotations. You can check this by cloning the repo that you created the release in to a new directory, and using git show v1.2.3 to compare tag annotations between repos.
What's interesting is that the annotation is read by gh, or else I couldn't use the git tag message as a template for the release notes.

[spenserblack]

Here's a repo that I made to test this out. You can fork it and use the script to try it out yourself.
Besides the tag message, it also looks like any GPG signature on the tag is also lost.

Edit (2022/01/28): I deleted the linked repo, but this gist has the script for testing.

[samcoe]

@spenserblack This behavior is mostly due to the restrictive nature of the release create API endpoint. It only allows for a tag name to be specified but no other properties, such as annotations, of the tag. The API will look in the repo for the tag or create a new one if one does not exist with the specified name, but the API won't have knowledge of a local non-pushed tag. Right now the workaround, as you mentioned, is to push the tag before doing release create. I don't see why gh couldn't handle this case though, but pushing a local tag if it exists locally and not on the remote. @mislav @vilmibm Is there any complexity here I am overlooking as to why we couldn't support this?

[guerinoni]

I'm testing a patch that check locally the tag and push it before doing the rest, in order to avoid the manual workaround :)

[guerinoni]

@spenserblack I just opened a PR, but maybe you can check the fix on my fork guerinoni:push-tag-locally-before-release :)