Edit or update an existing release

[tunetheweb]

What to implement:

# Flags
gh release edit my-tag-123 --title "my updated title"  # short: -t
gh release edit my-tag-123 --notes "short notes"       # short: -n
gh release edit my-tag-123 --notes-file long_notes.md  # short: -f

# mark as published
gh release edit my-tag-123 --publish   # no short

# prerelease status
# This acts as a toggle.
gh release edit my-tag-123 --prerelease # no short

# Interactive mode
# Note the default for "Is this a prerelease" should reflect what is currently set so hitting enter changes nothing.
gh release edit my-tag-123
? Title (my cool release) my updated release title
? Notes [e to edit notes, enter to skip]
? Is this a prerelease? [Yn]
https://github.com/blah/blah/releases/tag/my-tag-123

Original feature request below.

---

Describe the feature or problem you’d like to solve

The release-drafter GitHub Action automatically creates a draft release and adds to it as each Pull Request is merged.

It would be good if GitHub CLI could tag that draft release, add assets, and publish it.

At present it appears (from my limited understanding!) that GitHub CLI 1) can only create a new release or update a previously tagged release and 2) cannot publish a release. Please let me know if I’m mistaken.

Proposed solution

Perhaps provide gh release publish option that would take the same arguments as gh release create but allow a way of specifying latest draft as the release to base this on?

This would allow users to manage releases better from command line and/or automated scripts.

[mislav]

Thanks for the suggestion! Agreed that this should definitely get possible in the future 👍

[inktomi]

This is the last missing link in using gh to manage releases for me. I'm excited to begin using gh - but need this in first as managing releases is one of my primary uses for this tool. We create a draft release, build a bunch of stuff, upload it all, then mark the release complete. It'd be great if that whole flow could be scripted!

[mislav]

I have renamed this feature request to describe the more general feature of editing a Release, including changing its draft or pre-release status.

[peaceiris]

It will become a subcommand like hub release edit 👍

[kzu]

Sad to see no movement on this in almost a year 😢

[mingyjongo]

Bump! Could use this feature for my team and would love to hear any updates on prioritization here, even if it means it's off the table for the foreseeable future.

In case it helps anybody else, I'm currently working on a split flow in CI where a draft release is created in one step, artifacts are uploaded in another, and then a shell script will use the REST API to publish the draft. ((👈 this last part is annoying))

https://docs.github.com/en/rest/reference/releases#update-a-release

[vilmibm]

Here are mockups for a gh release edit command.

# Flags
gh release edit my-tag-123 --title "my updated title"      # short: -t
gh release edit my-tag-123 --notes "short notes"           # short: -n
gh release edit my-tag-123 --notes-file long_notes.md  # short: -f

# mark as published
gh release edit my-tag-123 --publish   # no short

# prerelease status
# This acts as a toggle.
gh release edit my-tag-123 --prerelease # no short

# Interactive mode
# Note the default for "Is this a prerelease" should reflect what is currently set so hitting enter changes nothing.
gh release edit my-tag-123
? Title (my cool release) my updated release title
? Notes [e to edit notes, enter to skip]
? Is this a prerelease? [Yn]
https://github.com/blah/blah/releases/tag/my-tag-123

[inktomi]

I'm going to try working on this over the next few weeks, thank you for the spec, and I'll use https://docs.github.com/en/rest/reference/releases#update-a-release as a reference for the REST call.

[NewtonChutney]

Any further update? If the feature has been implemented already we can proceed to close this issue?

[CB-TimLudwinski]

Any further update? If the feature has been implemented already we can proceed to close this issue?

It seems like changing prerelease and draft was implemented like this: --prerelease=false and --draft=false.