Add support for downloading packages from private sources #8
Conversation
This changeset provides support for downloading autobuild packages from restricted sources such as private repositories using GitHub release artifacts or GitLab generic packages. The way this works is by the addition of an optional installable parameter: `creds`, which may be specified when adding or editing dependencies: ``` autobuild installables edit my-pkg creds=github url=... ``` This property is used to inform autobuild that it should set a HTTP authorization header specific to the provider (github, gitlab) when downloading the respective artifact. In the future, this could be enhanced to include more providers or authorization schemes. The `autobuild install` command could also be enhanced with equivilent kwargs `--github-token` and `--gitlab-token`.
bennettgoble
force-pushed
the
signal/creds
branch
from
725c9e1 to
da0cc44
Compare
There was a problem hiding this comment.
I think my request is beyond the scope for this PR, but would it be a good idea to incorporate use of the python keyring module for handling these kind of credentials in the future?
Great idea. Yes, I think that should be looked into in the not-too-distant future. |
| except KeyError: | ||
| logger.warning(f"Unrecognized creds={creds} value") | ||
|
|
||
| token = os.environ.get(token_var) |
There was a problem hiding this comment.
Since we use the value of token_var in the same way for both AUTOBUILD_GITHUB_TOKEN and AUTOBUILD_GITLAB_TOKEN, why do we need two separate variables? Acknowledging that we may want different code paths for future kinds of auth tokens, maybe for now just use bearer and AUTOBUILD_BEARER_TOKEN to select this code path that creates an "Authorization: Bearer <token>" header?
There was a problem hiding this comment.
I think we want some kind of safety to avoid accidentally leaking github tokens to gitlab and vice versa
There was a problem hiding this comment.
Is that a real possibility? I'm assuming that mention of gitlab is purely theoretical so far, just because we happen to know that gitlab uses the same "Authorization: Bearer {token}" header.
There was a problem hiding this comment.
Theoretical for us. Real for third party contributors. I believe gitlab support originated with them in mind.
see also #19
This changeset provides support for downloading autobuild packages from restricted sources such as private repositories using GitHub release artifacts or GitLab generic packages.
The way this works is by the addition of an optional parameter:
creds, which may be specified when adding or editing dependencies:This property is used to inform autobuild that it should set a HTTP authorization header specific to the provider (github, gitlab) when downloading the respective artifact. An environment variable containing credentials is expected to be set per-provider in order to keep authorization strategies separate:
For example, a GitHub actions runner could do the following:
Future
This functionality could be enhanced to include more providers or authorization schemes. The
autobuild installcommand could also be enhanced with equivalent kwargs--github-tokenand--gitlab-token.