Add commands for managing GitHub Releases #1552

mislav · 2020-08-19T16:30:13Z

New commands:

gh release list
gh release view <tag>
gh release create <tag> [<files>...]
gh release upload <tag> <files>...
gh release download <tag> [<pattern>]

Example output:

Example help:

$ gh release create -h
Create a new release

USAGE
  gh release create <tag> [<files>...] [flags]

FLAGS
  -d, --draft             Save the release as a draft instead of publishing it
  -n, --notes string      Release notes
  -F, --notes-file file   Read release notes from file
  -p, --prerelease        Mark the release as a prerelease
      --target branch     Target branch or commit SHA (default: main branch)
  -t, --title string      Release title

INHERITED FLAGS
      --help                     Show help for command
  -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format

TODO:

Fixes #378

We install an HTTP middleware that adds the "Authorization" header on every HTTP request. However, our asset download process might redirect to a 3rd-party host (Amazon S3) and we want to allow those requests but not require that they are authenticated. Furthermore, we need the ability to specify the `Accept` request header without it being overwritten by middleware, so now middleware only adds headers that are not present in a request.

eddumelendez · 2020-08-26T04:19:13Z

looking forward to it 😍

ampinsk · 2020-08-26T20:39:21Z

I'm so excited for this one, it looks great! Had one nit from going through things:

Should we autocomplete the title from the tag?

$ gh release create 3.4.2
? Title (3.4.2)

mislav · 2020-09-01T17:23:44Z

Should we autocomplete the title from the tag?
$ gh release create 3.4.2
? Title (3.4.2)

@ampinsk We can consider this, but the release title is technically optional on the server and, if left blank, will inherit the title of the git tag (if any) or the subject of the git commit that the tag points to. If people are actively counting on this behavior by intentionally leaving the title blank, then by pre-filling the title to match the tag name, we effectively disallow that fallback on the client.

I'm on the fence about what the ideal behavior would be, but for the sake of predictability and parity with platform behavior, I'm currently leaning to allowing blank titles.

ampinsk · 2020-09-01T18:21:40Z

@mislav was definitely just a nit, totally fine with dropping it!

vilmibm

this was a lot to review at once >_>

i didn't see any blockers to merging, but had some light requests here and there so i'm marking request changes. overall i found the new commands to be very comprehensible and well organized, thanks!

vilmibm · 2020-09-01T16:52:47Z

api/client.go

 	return func(tr http.RoundTripper) http.RoundTripper {
 		return &funcTripper{roundTrip: func(req *http.Request) (*http.Response, error) {
-			req.Header.Add(name, value)
+			if len(req.Header.Values(name)) == 0 {


why forbid overriding, here? I would expect AddHeader to let me replace an existing header with a new value.

#1552 (comment)

vilmibm · 2020-09-01T16:54:09Z

api/client.go

+		ResponseHeader:  logTraffic,
+		ResponseBody:    logTraffic,
+		Formatters:      []httpretty.Formatter{&httpretty.JSONFormatter{}},
+		MaxResponseBody: 10000,


is this intentional? I do this a lot locally so I certainly wouldn't mind it being in trunk.

Good spot! Yes, it's intentional— I realized that I wasn't able to debug large response payloads without this.

is this intentional? I do this a lot locally so I certainly wouldn't mind it being in trunk.

vilmibm · 2020-09-01T17:31:17Z

api/client.go

 	return func(tr http.RoundTripper) http.RoundTripper {
 		return &funcTripper{roundTrip: func(req *http.Request) (*http.Response, error) {
-			req.Header.Add(name, value)
+			if req.Header.Get(name) == "" {


why prevent overriding, here? I'd think that repeated calls to AddHeader would update a header value, not silently fail to update.

It's a good question! The short answer is that I had to add the guard to allow file downloads. Without this change, a file download request would set an Accept: application/octet-stream, but additional Accept values would get added by our request middleware via AddHeader and AddHeaderFunc, and thus JSON payload would get returned and the download sabotaged.

When I then thought about our AddHeader and AddHeaderFunc utilities, I realized that they are more in the service of adding default request headers (e.g. default Accept, default User-Agent, default Authorization), but if a request already contained any of those headers explicitly, there would be no reason to apply the default.

You have a good point that maybe we should change the verb from "Add" to something else that reflects the current semantics better?

ah, that makes sense -- in that case yeah I think we can rename from AddHeader to something like SetHeaderDefault or similar

https://github.com/cli/cli/pull/1552/files#diff-9e30abd45545c3e865502cae5bf624d9

#1552 (comment)

#1552 (comment)

https://github.com/cli/cli/pull/1552/files#diff-9e30abd45545c3e865502cae5bf624d9

vilmibm · 2020-09-01T19:59:06Z

pkg/cmd/release/create/http.go

+}
+
+func publishRelease(httpClient *http.Client, releaseURL string) error {
+	req, err := http.NewRequest("PATCH", releaseURL, bytes.NewBufferString(`{"draft":false}`))


what is your motivation for moving away from client.REST? I don't have an issue with it, just curious.

First and foremost is because REST requires me to instantiate an api.Client, which is an outdated pattern that I would like us to move away from since it acted as a wrapper around http.Client, but did not provide any benefits.

An additional reason was that I was hoping to see how comfortable I was letting specific commands control most aspects of how they process HTTP requests. This is with the goal of decreasing inter-package dependencies. I'm satisfied by this approach, but I do believe that error handling should be shared between all commands, as well as authentication.

vilmibm · 2020-09-01T20:03:45Z

pkg/cmd/release/download/download.go

+		},
+	}
+
+	cmd.Flags().StringVarP(&opts.Destination, "dir", "C", ".", "The directory to download files into")


why C for this? D, d, or o all seem more intuitive

Good question! I guess I was biased towards -C because commands like tar, make, and git support it. Wget does -P, --directory-prefix. I will change to -D 👍

vilmibm · 2020-09-01T20:04:36Z

pkg/cmd/release/download/download.go

+	}
+
+	cmd := &cobra.Command{
+		Use:   "download <tag> [<pattern>]",


I think it's worth documenting what kind of pattern this can be; when I was testing this out I wasn't sure if it was glob, plain wildcard, or regular expression.

vilmibm · 2020-09-01T20:19:01Z

pkg/cmd/release/download/download.go

+	var downloadError error
+	for i := 0; i < len(toDownload); i++ {
+		if err := <-results; err != nil {
+			downloadError = err


I wonder if it's worth a break here if we're not going to collect errors per-download. Otherwise we're discarding errors for all but the last download which is confusing.

Good thought, but we cannot break here since we need to invoke <-results as many times as there were download jobs. You're right that all but the latest error gets discarded. Right now I don't think that's such an issue, but if people notice this, we could collect all errors into one meta-error

vilmibm · 2020-09-01T20:48:36Z

pkg/cmd/release/shared/fetch.go

+}
+
+// FindDraftRelease interates over all releases in a repository until it finds one that matches tagName.
+func FindDraftRelease(httpClient *http.Client, baseRepo ghrepo.Interface, tagName string) (*Release, error) {


does this exist because draft releases aren't included when using releases/tag/:foo? I'm confused how the Draft part of this function's name relates to what it actually does.

Yes, the API doesn't let us query draft releases by tag name (makes sense, since there can be multiple drafts referring to the same tag name), so I have to resort to listing all releases. You are right that this lookup returns any release that matches a tag, not necessarily draft. To stay true to the function name, I will add code that only scopes the lookup to draft releases.

vilmibm · 2020-09-01T21:01:29Z

pkg/iostreams/color.go

+	bold    = ansi.ColorFunc("default+b")
+)
+
+func NewColorScheme(enabled bool) *ColorScheme {


i like this approach to color! but please open a tech debt issue to port the whole codebase to it so we don't end up with competing color systems.

tierninho · 2020-09-04T18:17:47Z

Two questions, is this path error due to the test mode or a bug?

gh release create TAG1 -R tierninho/blah
? Title TRIAL
? Release notes Write my own
/var/folders/cn/b6t8mw1s6xqcfysnl8jfjdg80000gn/T/874767777.md:1: command not found: \ufeff
exit status 127

and is it ok to skip the title? It will create a Draft title more than once.

gh release create TAG1 -R tierninho/blah
? Title
? Release notes Leave blank
? Is this a prerelease? No
? Submit? Save as draft
https://github.com/tierninho/Blah/releases/tag/untagged-caba1054e408fa5fef50

Questions:

where are the assets downloaded to if you use the -R flag?
is there a -w flag coming as it might be useful in gh release view [tag] -w for instance?
Should there be a success message if upload succeeded?
Is the -d and -p supposed to be allowed at same time? I looks life a draft supersedes a prerelease.

vilmibm · 2020-09-08T22:10:09Z

@tierninho

Two questions, is this path error due to the test mode or a bug?

that error looks related to a bad value set for editor?

mislav · 2020-09-09T12:18:36Z

@tierninho All great questions!

where are the assets downloaded to if you use the -R flag?

The same as without the -R flag: the current directory, or the one specified by --dir.

is there a -w flag coming as it might be useful in gh release view [tag] -w for instance?

That's a good idea! I will add it.

Should there be a success message if upload succeeded?

We haven't talked about it, but a message like “6 files successfully uploaded” might be nice. I'll consider adding it!

Is the -d and -p supposed to be allowed at same time? I looks life a draft supersedes a prerelease.

Yes because a draft will usually get published, and when it does then the original "prerelease" bit will matter. The "draft" and "prerelease" bits are thus independent of each other.

cyrilletuzi · 2020-09-09T20:38:23Z

@mislav First, thank you for this feature! <3

But is there a way to use the latest created tag (for example gh release create latest), instead of having to write the tag number manually (ie. gh release create v1.0.1)?

It seems very important to me to really be usable in an automation process. For exemple:

for my VS Code extension, my release script is:

vsce publish patch && git push && git push --tags

for my npm packages, my release script is:

npm run build && npm version minor && npm publish dist && git push && git push --tags;

In both cases, the tag creation is automated (by vsce publish or npm version), so I don't have access to the tag number directly. So I would not be able to be able to add the last automation step with gh release create.

mislav · 2020-09-10T11:48:12Z

@cyrilletuzi That's an excellent feature request and something that I haven't considered; thank you! Would you mind opening a separate issue so we can discuss and track this?

In the meantime, would it be an option for you to use the output of git tag --sort=-creatordate | head -1?

mislav added 6 commits August 19, 2020 18:25

Preliminary gh release commands

c4f5d6d

Add release upload command

4e05db9

Add release download, upload files on create, upload retrying

a00d927

Log larger response bodies with DEBUG=api

cf46ae2

Add interactive flow for release create

4f6021a

mislav marked this pull request as ready for review August 21, 2020 16:35

mislav added 2 commits August 25, 2020 20:20

Offer different editor modes during release create

f7d0988

Update release list output to contain badges

9829a4d

mislav added 5 commits August 28, 2020 17:41

Add release delete

d43d5e0

Merge remote-tracking branch 'origin' into release-cmd

9a4a5d8

Add tests for release list/delete

9b45112

View latest release if no tag provided

d0d9cc2

Provide machine-readable release view output

9ef1791

vilmibm mentioned this pull request Sep 1, 2020

properly check for tty when in powershell #1607

Merged

vilmibm self-requested a review September 1, 2020 15:49

mislav added 3 commits September 1, 2020 18:56

Add tests for release create, delete, download, view

0f42c7a

Fix date-based release output and tests

4976bd7

Restore Go 1.13 compatibility

6933c38

vilmibm suggested changes Sep 1, 2020

View reviewed changes

mislav added 5 commits September 2, 2020 22:11

Try fixing Windows tests

02a057a

Fix .zip and .js overrides for Windows

151a734

Allow downloading assets from the latest release

d4b45c6

Have FindDraftRelease be truer to its name

1ad9b0b

Fix reporting release URL when creating with assets

a470d49

mislav mentioned this pull request Sep 4, 2020

Decouple from ANSI colors utilities in utils package #1624

Closed

vilmibm approved these changes Sep 8, 2020

View reviewed changes

mislav added 8 commits September 9, 2020 15:27

Merge remote-tracking branch 'origin' into release-cmd

ad0bbde

Add the release view --web flag

3d58fa7

Consistently print browsed URL across commands

fda9659

Add success message to release upload

202d111

Add docs to release create/upload

7614ffe

Allow specifying multiple patterns in release download

1ce61d4

Fix view tests

9040f6a

Indicate that title is optional in release create

50d5813

mislav merged commit f30bc5b into trunk Sep 9, 2020

mislav deleted the release-cmd branch September 9, 2020 16:07

ocdtrekkie mentioned this pull request Sep 9, 2020

Implement GitHub Actions for releases sandstorm-io/vagrant-spk#256

Open

cyrilletuzi mentioned this pull request Sep 11, 2020

Default to last created tag in gh release create #1674

Closed

This was referenced Sep 14, 2020

Add a command for downloading a new release #1394

Closed

Fix release download #1697

Merged

Issue with create release (and possibly other gh api POST requests) #1698

Closed

felipecrs mentioned this pull request Sep 16, 2020

gh release create --checksums #1711

Open

vilmibm mentioned this pull request Sep 16, 2020

Listing releases and assets #1353

Closed

cli blocked thor795 Sep 21, 2020

dsayling mentioned this pull request Oct 5, 2020

New orb release should also create a github release from tag CircleCI-Public/orb-tools-orb#101

Closed

mislav mentioned this pull request Feb 24, 2021

Accessing draft releases is not possible using GITHUB_TOKEN in Actions #3037

Closed

andyfeller mentioned this pull request Nov 26, 2024

Print friendly error when release create fails due to missing workflow OAuth scope #9791

Merged

Uh oh!

Add commands for managing GitHub Releases #1552

Add commands for managing GitHub Releases #1552

Uh oh!

Conversation

mislav commented Aug 19, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eddumelendez commented Aug 26, 2020

Uh oh!

ampinsk commented Aug 26, 2020

Uh oh!

mislav commented Sep 1, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ampinsk commented Sep 1, 2020

Uh oh!

vilmibm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tierninho commented Sep 4, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vilmibm commented Sep 8, 2020

Uh oh!

mislav commented Sep 9, 2020

Uh oh!

cyrilletuzi commented Sep 9, 2020

Uh oh!

mislav commented Sep 10, 2020

mislav commented Aug 19, 2020 •

edited

Loading

mislav commented Sep 1, 2020 •

edited

Loading

tierninho commented Sep 4, 2020 •

edited

Loading