Opt-in to use GitHub API to fetch releases

[abhinav]

Hello! I'm trying to use Hermit to distribute private GitHub packages. However, it appears that it's necessary to distribute a custom build with PackageSourceSelector set to cache.GitHubSourceSelector(originalGetSource, ghClient, ...). This makes bootstrapping a bit difficult: one needs a distribute a custom build of Hermit to be able to download the custom build of Hermit from a private repository.

Looking at main: https://github.com/cashapp/hermit/blob/991aa47af75148b33ae7e00089103909d775fffa/app/main.go#L229 Hermit already knows your GitHub token (if any) and constructs a GitHub client with it.

Would it make sense to add an opt-in for GitHubSourceSelector with that client based on, say, a configuration parameter set in hermit.hcl? Hypothetically:

# bin/hermit.hcl
githubSource {
    match = ["myorg/*"]
}

(Obviously, config proposal can be changed as you see fit. Or it can be env-based if that's your preference.)

This would allow Hermit to be used for private releases without a custom build: as long as GITHUB_TOKEN or HERMIT_GITHUB_TOKEN is set, it would just work. (Theoretically, there's room in the future for the token to come from an external command, e.g. a password manager or Keychain, but that's an issue for another day.)

If a change in this direction makes sense, I'm happy to make a PR.

[alecthomas]

The idea seems reasonable. Maybe something like:

github-token-auth {
  match = ["myorg/*"]
}

[abhinav]

Sounds great! I'll have a go at it soon.

[abhinav]

Took an initial stab at this in https://github.com/cashapp/hermit/pull/409. Although I've verified locally that that works, it's not clear to me how to fit a test for that in the current integration test harness. To do that right, we would need a means of overriding the GitHub base URL and the GitHub API URL. Then a net/http/httptest server could verify that the request was properly authenticated.