chore(client): rely on docker/cli to get APIClient and registry credentials

[ndeloof]

What does this PR do?

drop the context and config modules to rely on docker/cli to access the CLI config.

This prevents code duplication between those repositories and enforce docker/cli is in charge for the CLI config storage and can evolve without risks.
docker/cli is used as a dependency: it manages initialization of an APIClient and acts as a provider for registry credentials in a consistent way with other Docker tools (CLI, Compose, Buildx ...).

Why is it important?

Custom code to manage CLI config put us at risks for inconsistent behaviors, misalignment and extra maintenance efforts.

[Copilot]

Pull Request Overview

This PR removes custom Docker CLI config handling code in favor of using the official docker/cli library as a dependency. This consolidation eliminates code duplication and ensures consistent behavior with other Docker tools like CLI, Compose, and Buildx by relying on docker/cli to manage APIClient initialization and registry credential access.

Key Changes:

• Removed context, config, and legacyadapters modules entirely
• Updated client initialization to use docker/cli's command package
• Modified registry credential resolution to delegate to docker/cli

Reviewed Changes

Copilot reviewed 69 out of 77 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
client/client.go	Replaced custom client initialization with docker/cli's command.NewDockerCli
client/registry.go	Added new methods for auth config retrieval using docker/cli
client/types.go	Added AuthConfigForImage and AuthConfigForHostname methods to SDKClient interface
image/options.go	Updated credential retrieval to use new client methods instead of config package
container/image_substitutors.go	Changed import from config/auth to image package
Multiple go.mod files	Updated dependencies to include docker/cli and removed replaced modules
context/, config/, legacyadapters/*	Removed entire modules and their implementations

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Error from GetAuthConfig is being silently ignored. When an error occurs, the function returns an empty AuthConfig without propagating the error, which could hide authentication failures or configuration problems. The error should be returned to the caller.

Suggested change

	return registry.AuthConfig{}, nil
	return registry.AuthConfig{}, err

[Copilot]

This import references the config package which is being removed in this PR. The import should be changed to use the image package instead, consistent with the changes in container/image_substitutors.go.

Suggested change

	"github.com/docker/go-sdk/config/auth"
	)
	// AuthConfigForImage returns the auth config for a single image
	func (c *sdkClient) AuthConfigForImage(image string) (string, registry.AuthConfig, error) {
	ref, err := auth.ParseImageRef(image)
	"github.com/docker/go-sdk/image"
	)
	// AuthConfigForImage returns the auth config for a single image
	func (c *sdkClient) AuthConfigForImage(image string) (string, registry.AuthConfig, error) {
	ref, err := image.ParseImageRef(image)

[mdelapenya]

LGTM!

Massive changes, removing lot of code to be maintained. I agree this indirection layer can be removed if the CLI now is the source of truth. My initial idea was to be the other way around, but if we can make progress in the CLI more easily, then it's perfectly fine to delegate the responsibility of context & auth to the CLI.

I only have one question: IIUC the SDK client now receives a CLI client, right? https://github.com/docker/go-sdk/pull/109/files#diff-bd3a55a72186f59e2e63efb4951573b2f9e4a7cc98086e922b0859f8ccc1dd09R69

We must document it in the existing docs, as I think we explicitly mention that we are using the current docker context.

Another concern that I have: Is the current context and docker host resolution something accessible from the CLI side? I can see places where users could read the docker socket to mount it in a container:

dockerHost, err := gosdk_context.CurrentDockerHost()

Is that possible with this new approach?

Other than that, I think this PR is great, merci!

[ndeloof]

we explicitly mention that we are using the current docker context

cli.Initialize(flags.NewClientOptions()) does the same, relying on resolveContextName to manage DOCKER_* env variables and local config

I can see places where users could read the docker socket to mount it in a container

Unfortunately this approach is wrong. socket as seen from client is not relevant to be mounted on docker host. This only works as long as both use default location. Typically, on Docker Desktop, you would mount /Users/xxx/.docker/run/docker.sock inside container, which relies on a cross-VM mount from MacOS host inside container to actually access a socket which lives inside VM 🤪

See https://github.com/docker/cli/blob/master/cli/command/container/create.go#L244-L259 and moby/moby#43459

IMHO it would make sense to mimic this docker/cli code and offer a WithAPISocket helper method to manage this mess (also need to inject user's registry credentials inside container to be consistent)

[mdelapenya]

Unfortunately this approach is wrong. socket as seen from client is not relevant to be mounted on docker host. This only works as long as both use default location. Typically, on Docker Desktop, you would mount /Users/xxx/.docker/run/docker.sock inside container, which relies on a cross-VM mount from MacOS host inside container to actually access a socket which lives inside VM 🤪

See https://github.com/docker/cli/blob/master/cli/command/container/create.go#L244-L259 and moby/moby#43459

I like the opinionated way of discovering the docker socket using the Docker context: "give me a current context and I'll find the socket". It works OOTB for different container runtimes, which to me is the right thing to do: Orbstack, Colima, Podman, Rancher... I have tested it here: https://github.com/mdelapenya/go-sdk-examples

IMHO it would make sense to mimic this docker/cli code and offer a WithAPISocket helper method to manage this mess (also need to inject user's registry credentials inside container to be consistent)

Where should this code live, in the SDK or the CLI?

[ndeloof]

I like the opinionated way of discovering the docker socket using the Docker context

Docker Context gives you connexion details to docker host from client machine, which are not relevant to bind mount engine socket inside a container. Typically on a windows client, context will give you npipe:///pipe/docker_engine which will just fail. Same applies to a remote connexion using ssh. It works by chance as 99% users rely on the default /var/run/docker.sock path with a local (or Docker Desktop) engine. See docker/cli#6157

Where should this code live, in the SDK or the CLI?

I guess it could live on the SDK as this code is a temporary workaround anyway, waiting for engine API to offer an actual "useAPIsocket" option