Skip to content

Conversation

@miwurster
Copy link
Contributor

Hi, this PR adds support to download the repository content as zip or tar archive.

I extended the Repository client with two separate methods to download the tar or zip archive. The methods return an Optional InputStream that can be consumed accordingly, e.g., by a BufferedInputStream that writes it read bytes to a FileOutputStream or by following this guide.

@ebk45
Copy link
Contributor

ebk45 commented Dec 22, 2023

Hi @miwurster.

We apologise for taking so long to get eyes on this PR, we haven't been able to maintain this library to the standard we would have liked to but this will be changing in the new year. If you could please get this rebased and we'll be prioritising all open PRs ready for review.

Thanks!

Ellie

@codecov
Copy link

codecov bot commented Dec 28, 2023

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (24b73da) 76.64% compared to head (c068e86) 76.84%.
Report is 2 commits behind head on master.

Files Patch % Lines
...om/spotify/github/v3/clients/RepositoryClient.java 90.90% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##             master     #152      +/-   ##
============================================
+ Coverage     76.64%   76.84%   +0.20%     
- Complexity      289      296       +7     
============================================
  Files            42       42              
  Lines           989     1002      +13     
  Branches         43       44       +1     
============================================
+ Hits            758      770      +12     
- Misses          206      207       +1     
  Partials         25       25              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

- separate methods to download the tar or zip archive
- methods return an Optional InputStream that can be consumed
@miwurster
Copy link
Contributor Author

Rebased and ready for review.

Copy link
Contributor

@felix-seifert felix-seifert left a comment

Choose a reason for hiding this comment

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

Nice feature addition. 😀 You should just avoid the usage of null. In this repo, we might be using null every now and then. However, we should really change this. 🙈

.request(new Request.Builder().url("https://example.com/whatever").build())
.protocol(Protocol.HTTP_1_1)
.message("")
.code(204) // No Content
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice that you described the status code with a short comment. 👍 (No need to change anything)

}

private CompletableFuture<Optional<InputStream>> downloadRepository(final String path, final String ref) {
final var repoRef = Strings.nullToEmpty(ref);
Copy link
Contributor

Choose a reason for hiding this comment

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

Having to handle null is not nice and might introduce bugs in future iterations. The obvious goto would be Optional. However, it might not always be the nicest in method calls. Furthermore, using it makes the method overloading redundant.

My suggestion here is to use Optional only for your private method: downloadRepository(final String path, final Optional<String> maybeRef). Your repoRef could then become something like maybeRef.orElse("").

In methods like downloadZipball(), you would then not call the same method with null but downloadRepository(REPOSITORY_DOWNLOAD_ZIPBALL, Optional.empty()).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah sure, I'll change that after lunch :-)

@miwurster
Copy link
Contributor Author

Implemented review comments

Copy link
Contributor

@felix-seifert felix-seifert left a comment

Choose a reason for hiding this comment

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

I was wondering whether we should make it more obvious that we test for specific refs. Currently, we have this tested in shouldReturnEmptyOptionalWhenResponseBodyNotPresent(), i.e. the request has to work for the ref master. However, this test does not explain this specifically.

Might be interesting to test this but I think it is not worth the effort.

@felix-seifert felix-seifert merged commit 3f07b24 into spotify:master Dec 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants