Skip to content

Adding gh release download for .zip and .tar.gz#4489

Merged
mislav merged 3 commits intocli:trunkfrom
lpessoa:lp-2167
Nov 30, 2021
Merged

Adding gh release download for .zip and .tar.gz#4489
mislav merged 3 commits intocli:trunkfrom
lpessoa:lp-2167

Conversation

@lpessoa
Copy link
Contributor

@lpessoa lpessoa commented Oct 11, 2021

Fixes #2167

Adding gh release download support for fetching the default .zip or .tar.gz release files.

The user will be able to require the files by simply adding the --archive command line parameter.

gh release download v1.3.0 --archive=tgz

  • Implement basic functionality
  • Add stricter argument validations
  • Create tests

@lpessoa lpessoa marked this pull request as ready for review October 11, 2021 23:26
Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for working on this; this is shaping up great!

A general note about ZipballURL/TarballURL API endpoints: this might not be immediately apparent, but these APIs result in a "legacy" format of the zip/tgz archive when compared to the archives downloaded by using the "Source code" download links from the web interface. Ideally this would be consistent with the web, as I personally don't like the legacy archive format and find the non-legacy format way more useful. However, you don't need to address this in your PR; I'm asking other people at GitHub more knowledgeable about Releases as to what we could potentially do here.

Copy link
Contributor Author

@lpessoa lpessoa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review changes implemented. Added a little helper to httpmock to allow setting a Header value for the Responder's http.response (can be easilly converted to accept multiple headers).
Just a small question regarding the scenario where the content-disposition header is missing from the server (should not happen 😄 )

@lpessoa lpessoa requested a review from mislav October 13, 2021 17:32
Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Only minor bits remaining

@lpessoa lpessoa requested a review from a team as a code owner October 13, 2021 22:51
@lpessoa lpessoa requested review from mislav and removed request for a team October 13, 2021 23:08
Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

I will hold off merging until we internally resolve the question of how do we access non-legacy zipball/tarball archives (see my previous review) using the public API.

@shiouen
Copy link

shiouen commented Nov 24, 2021

awesome @lpessoa!

@mislav any update on that internal question?

@mislav mislav added the platform Problems with the GitHub platform rather than the CLI client label Nov 24, 2021
@mislav
Copy link
Contributor

mislav commented Nov 24, 2021

@shiouen No movement from the platform side. It looks like we might be stuck with the currently available API that redirects to legacy tarball/zipball format. However, we can take control over the HTTP redirect and remove the legacy. bit from the codeload URL manually in order to access non-legacy formats. It's a hack, but I think it's a worthwhile one. I'll try to add it to the PR!

lpessoa and others added 3 commits November 30, 2021 15:52
Co-authored-by: Mislav Marohnić <mislav@github.com>
The `zipball_url` and `tarball_url` fields on the Release API payload
always link to "legacy" archives that are of a different format than
those one would get if they downloaded an archive from a Release using
the web interface. The GitHub API does not seem to publish links to
non-legacy archives.

This adds a redirect hack to turn "legacy" Codeload URLs into non-legacy
ones with the goal of ensuring the consistency of user experience when
downloading archives.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

platform Problems with the GitHub platform rather than the CLI client

Projects

None yet

Development

Successfully merging this pull request may close these issues.

gh release download is not working for .zip and .tar.gz release assets

4 participants