We currently have GithubRepo.get_contents as an abstraction around GitHub's Contents API endpoint. However, this endpoint behaves differently depending on what you're asking it for, in particular:
- a directory
- a file
- a file whose size is between 1MB and 100MB
- a file whose size is above 100MB
The method tries to handle those all in one place and the flow suffers because of it.
Instead we should pick apart this abstraction into two, based on the caller's intent:
- a directory
- a file, with fallbacks for larger files
For instance, file content for files between 1MB and 100MB can be retrieved with the application/vnd.github.v3.raw custom media type (as the Accept header). Since we already want the metadata from the initial call (it's not provided with a raw call) this seems like a nice fallback. We can discuss whether we need to support retrieving file content which is >100MB.
We currently have
GithubRepo.get_contentsas an abstraction around GitHub's Contents API endpoint. However, this endpoint behaves differently depending on what you're asking it for, in particular:The method tries to handle those all in one place and the flow suffers because of it.
Instead we should pick apart this abstraction into two, based on the caller's intent:
For instance, file content for files between 1MB and 100MB can be retrieved with the
application/vnd.github.v3.rawcustom media type (as theAcceptheader). Since we already want the metadata from the initial call (it's not provided with a raw call) this seems like a nice fallback. We can discuss whether we need to support retrieving file content which is >100MB.