Skip to content

gh release create: Allow tag names for --target #5855

Open
Open
gh release create: Allow tag names for --target#5855
Labels
blockedenhancementa request to improve CLIgh-releaserelating to the gh release commandplatformProblems with the GitHub platform rather than the CLI client

Description

@victorlin
victorlin
opened on Jun 27, 2022

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

  1. victorlin
    added
    enhancementa request to improve CLI
    on Jun 27, 2022
  2. cliAutomation
    added
    needs-triageneeds to be reviewed
    on Jun 27, 2022

  3. spenserblack commented on Jun 27, 2022

    @spenserblack
    spenserblack
    on Jun 27, 2022
    Contributor

    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?

  4. mislav commented on Jul 11, 2022

    @mislav
    mislav
    on Jul 11, 2022
    Contributor

    Thanks for the context everyone. I've just gone and looked at the platform code and it seems like --target only 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 create will never automatically create the git tag is to first ensure that the git tag is pushed.

  5. mislav
    added
    blocked
    platformProblems with the GitHub platform rather than the CLI client
    and removed
    needs-triageneeds to be reviewed
    on Jul 11, 2022

  6. victorlin commented on Jul 11, 2022

    @victorlin
    victorlin
    on Jul 11, 2022
    Author

    I see it calls the Releases API, where --target maps to target_commitish:

    Specifies the commitish value that determines where the Git tag is created from. Can be any branch or commit SHA. Unused if the Git tag already exists. Default: the repository's default branch (usually master).

    @mislav thanks for pointing out that this is a platform issue.

  7. mislav commented on Jul 11, 2022

    @mislav
    mislav
    on Jul 11, 2022
    Contributor

    Note that CLI documentation for release create also says:

    --target branch                Target branch or full commit SHA (default: main branch)

    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.

  8. spenserblack commented on Jul 11, 2022

    @spenserblack
    spenserblack
    on Jul 11, 2022
    Contributor

    I'm just guessing, but maybe target_commitish can't be a tag for /repos/{owner}/{repo}/releases because tag_name is already used for tags? In fact, the docs say

    [target_commitish is] unused if the Git tag already exists.

    If 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.0

  9. victorlin commented on Jul 11, 2022

    @victorlin
    victorlin
    on Jul 11, 2022
    Author

    @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-tag which overrides the default behavior of creating the tag if it doesn't exist.

  10. michaelmdresser commented on Nov 3, 2022

    @michaelmdresser
    michaelmdresser
    on Nov 3, 2022

    I am also interested in having a flag like @victorlin is suggesting to ensure that gh release create does not create a tag.

  11. victorlin commented on Nov 4, 2022

    @victorlin
    victorlin
    on Nov 4, 2022
    Author

    @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!

  12. andyfeller
    added
    gh-releaserelating to the gh release command
    on Oct 2, 2023
  13. Emasoft
    added a commit that references this issue on Dec 13, 2025

    feat(release): Add configurable release_conf.yml support

    5077fb6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    blockedenhancementa request to improve CLIgh-releaserelating to the gh release commandplatformProblems with the GitHub platform rather than the CLI client

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions