Export pull as a public function #1026
Conversation
It will be helpful to expose the pull implementation which supports pulling private images for other CLI commands that rely on helper images. Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
|
|
||
| func runPull(cli command.Cli, opts pullOptions) error { | ||
| // RunPull performs a pull against the engine based on the specified options | ||
| func RunPull(cli command.Cli, opts PullOptions) error { |
There was a problem hiding this comment.
I'm a bit unsure if this is the right functionality to export, i.e.; what exact functionality are you looking for? Just pulling a specific image, or also Including the option to pull --all-tags? Having an error when attempting to pull a plugin? If new options are added to docker pull should they be automatically be added to the other parts?
There was a problem hiding this comment.
I'm certainly open to suggestions on refinement...
The use-case I was looking at was a higher level construct that uses helper images to accomplish a task in the CLI. Conceptually equivalent to:
docker pull someimagethatmightbeprivate:tag
docker run -v /var/lib/docker.sock:/var/lib/docker.sock someimagethatmightbeprivate:tag dowork
The main thing I was trying to DRY out was all the logic around dealing with the credential cache for logins. My thinking was we might need the knobs and dials that docker pull exposes so exposing the high level CLI function/options could be useful.
There was a problem hiding this comment.
If you think that's too high-level/abstract given the current requirements, perhaps a different approach is to create a new helper in the trust package that takes a repo, and coughs out an authConfig struct suitable to pass into the standard engine-api Pull routine after base64 encoding it?
There was a problem hiding this comment.
Got it; yes, we could probably have something that can be shared (just wanted to be cautious to not introduce dependencies between commands if not needed; the PullOptions and error-handling looked very specific to docker pull)
@dnephin @vdemeester wdyt? suggestions?
There was a problem hiding this comment.
This seems fine to me as long as it can be used as-is.
If we need to introduce any changes for the new caller I think we should refactor to expose a different interface to accommodate the changes.
There was a problem hiding this comment.
If we need to introduce any changes for the new caller I think we should refactor to expose a different interface to accommodate the changes.
Agreed.
At this point I don't think we need to make any changes.
There was a problem hiding this comment.
Looks like we're ok to (at least for now) export this function 👍
4 participants
It will be helpful to expose the pull implementation which supports
pulling private images for other CLI commands that rely on helper images.
Signed-off-by: Daniel Hiltgen daniel.hiltgen@docker.com