Supporting Private GitHub repos and other artifact stores #816
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #684 (potentially)
Related issue: #684
Overview
Hi all, I am looking for some initial implementation feedback on supporting private GitHub repository releases as well as a few other potential artifact repositories.
The intent here is to support some way of running custom commands, which return an artifact file via stdout. This could solve #684 by running something like
gh api -H Accept:application/octet-stream /repos/kubernetes-sigs/krew/releases/assets/55894121
to download artifacts from a private GitHub repo's release assets. It could also allow people to have their on private krew indexes which rely upon local machine tooling to get the artifacts. I'm thinking example commands likeaws s3 cp s3://my-fancy-private-bucket/my-cool-krew-plugin.tgz -
. This type of support could separate the concerns of auth to the local machine running the installation.I initially wanted to implement this as an S3 SDK scheme but decided it would be better to enable more options via running commands on the local machine. Happy to discuss alternative approaches here too.
Early feedback request on the design
Keep in mind my testing and work is pretty rough and just an initial concept.
Should this implementation bloat the
uri
spec key to support other "schemes" (such asfile://
andcmd://
) or should it really be a separate key in the plugin manifest spec? (Providing string likecmd://run-my-super-sweet-script -i thing -o otherthing
just feels kinda not ideal.)Should this leverage temp files on the file system to "buffer" the stdout from the "artifact download command"? I initially attempted to use
exec.Command()
andexec.Command().Stdout()
but hit issues with the pipe closing before the stream could be read (appears to be howexec.Command()
is intended to function).Is this introducing too much of a security risk, allowing manifests to effectively execute arbitrary code via krew when installing plugins?
Below is an example plugin manifest using this PR to give an example of how this is written right now.