Support gh release edit

[plu]

Adds support (non-interactive) for updating a release.

Currently without any interactive part, only via command line parameters.

Unfortunately I could not reopen #5421 - and sorry for not providing any description upfront.

Examples:

Publish a release that was previously a draft
$ gh release edit v1.2.3 --draft=false

Mark a release as a prerelease
$ gh release edit v1.2.3 --prerelease

Mark a release as a full release
$ gh release edit v1.2.3 --prerelease=false

Update the target commitish of a release
$ gh release edit v1.2.3 --target 97ea5e77b4d61d5d80ed08f7512847dee3ec9af5

Update the name of the tag
$ gh release edit v1.2.3 --tag v9.8.7

Update the name/title of a release
$ gh release edit v1.2.3 --title 'Some new title'

Update the release notes
$ gh release edit v1.2.3 --notes 'Some short release notes'

Update the release notes from the content of a file
$ gh release edit v1.2.3 --notes-file /path/to/release_notes.md

[mislav]

Hi, thanks for this! This is going in a good direction.

What do you think of renaming the command to edit? We also have gh repo edit, gh issue edit, so gh release edit would be consistent with that. Also, the web UI for Releases renders an “Edit” button, so it looks like the verb "edit" might be more familiar to GitHub users, even though "update" is a perfectly valid verb as well.

[samcoe]

Just chiming in to link the issue for editing a release #1997 and additionally the mocks in this comment #1997 (comment)

[plu]

Hi Mislav,

thank you for all your guidance and detailed comments. I've tried to address all of them in a series of commits. If you see something else that could be improved, or is wrong, please let me know and I'm happy to make another set of changes.

I'm a bit surprised by the API behaviour: On the web interface of GitHub I've created a draft release, pointing to some tag (v2.5.0)

Now when I just update the release notes (body) of this release, the previously specified tag is lost.

gh release edit v2.5.0 --notes 'bsdf'

Only sending the body parameter in the PATCH request to https://api.github.com/repos/plu/cli/releases/63899317

Once this request finished, the previously specified tag is lost:

Wondering what implications it has on the new edit command. Should I always send the tag_name parameter with whatever the user specified in gh release edit <tag_name>? And only if the user wants to update the tag via --tag <new_tag_name> I'd send that value?

[mislav]

@plu That indeed sounds like a bug and I've just confirmed this. In this case, please send the tag_name parameter every time like you've suggested, even if the user hasn't changed it.

Additionally, I wonder if release edit should have flag --discussion-category like release create does? Specifying the discussion category would make sense when publishing a draft release with --draft=false.

[mislav]

Looks great! Withholding approval until all what was discussed for this PR is finalized.

[plu]

Thank you again for your feedback, Mislav.

One more thing I'm wondering: Sam linked some issue (#1997) where the release edit command was sketched. There a flag --publish was mentioned, which I like better than --draft=false. I'm wondering if it would be a good UX if we'd provide both flags, --publish and --draft. We'd make them mutually exclusive and throwing an error if both are specified. And also make them do the right thing just in case somebody uses --publish=false (draft) or --draft=false (publish).

What do you think?

[mislav]

Looks great! I've pushed a small fix for when no flags are passed.

There a flag --publish was mentioned, which I like better than --draft=false. I'm wondering if it would be a good UX if we'd provide both flags, --publish and --draft.

I do generally like the idea of --publish flag, but I don't think it's required for this iteration, especially because you've already included in the documentation the --draft=false example. I will go ahead and ship this as-is and we can potentially continue the discussion about --publish in a separate thread if we find evidence that our users would benefit from extra clarity.

[plu]

Thank you!