2

I use a read-only deployment key to clone a private Github repo into a Docker container. However, it doesn't seem possible to use that same deployment key to download a file from a Release. In particular, downloading a file from a release only seems to be possible by using a personal access key. For instance, here is one such tool to do that:

https://github.com/gruntwork-io/fetch

It seems that all of these responses focus on using personal access tokens instead of deployment keys:

How do I download binary files of a GitHub release?

How to download GitHub Release from private repo using command line

However, I have yet to see anybody indicating that it is not possible. So am I just missing something? Is it possible to download a file from a release (or hell.. a whole release) using a deployment key (not a personal access key)?

I need to have a key that is not tied to one of the maintainer's user accounts and I hate the idea of creating some throw-away phantom user solely for the purpose of automating downloads. After all, the phantom account is going to be tied to somebody's account, and I don't like the idea of that.

bremen_matt
  • 6,902
  • 7
  • 42
  • 90

1 Answers1

5

It's not possible to use a deployment key to download a release. A deployment key is an SSH key, and on GitHub, SSH functionality is limited to fetching and pulling.

When you want to download an archive, fetch a raw file, or perform any other action that uses HTTPS, you need HTTPS credentials. That can be a personal access token, or an OAuth token from an OAuth app enabled on your account. SSH keys can't be used for that, because they're for a different protocol.

The way it sounds like is probably best for you is by using an OAuth application which has access to the organization's account. That will help avoid the problem where a particular user leaves the organization.

You could also download the repository and use git archive to produce an archive on your own (or extract just the files you want by combining it with tar). That, of course, wouldn't be as efficient.

bk2204
  • 64,793
  • 6
  • 84
  • 100