pants docker_image does not work with Docker Desktop for Windows

[wfscheper]

Describe the bug Trying to build a docker image with pants in WSL2 using Docker Desktop for Windows fails with:

#3 [internal] load metadata for registry/repo/image:tag
#3 sha256:4b1c3b88e78faca34609335519aa97ddf79a93010f41361984334d033303f28a
#3 ERROR: rpc error: code = Unknown desc = error getting credentials - err: exit status 1, out: ``

Note I had to add PATH to the docker.env_vars so that docker could find docker-credentials-desktop.exe.

Pants version v2.9.0

OS Windows with WSL2 + Docker Desktop for Windows v4.4.2

Additional info I can provide more of the pants output if needed, but I'll need to redact it so I'm limiting to just the error message for now.

[Eric-Arellano]

Hello! Do you know if it's only failing for certain things like credentials?

I wonder if you could get a trivial "hello world" docker_image to build, something as simple as this (which generates a Dockerfile for you):

docker_image(
  name="docker",
  instructions=[
    "FROM python:3.8",
    "RUN echo 'hello'",
  ]
)

It'd be great to test that out with ./pants package path/to:docker and ./pants run path/to:docker, per https://www.pantsbuild.org/docs/docker.

[wfscheper]

Tried the minimal setup you suggested, but it still fails. Looks like it tries to do a login regardless:

$ ./pants package wsl-test:docker
10:09:02.62 [INFO] Initializing scheduler...
10:09:02.65 [WARN] File handle limit is capped to: 4096. To avoid 'too many open file handle' errors, we recommend a limit of at least 10000: please see https://www.pantsbuild.org/docs/troubleshooting#too-many-open-files-error for more information.
10:09:02.71 [INFO] Scheduler initialized.
10:09:05.65 [INFO] Completed: Building docker image repo/wsl-test:latest
10:09:05.65 [ERROR] 1 Exception encountered:
 ProcessExecutionFailure: Process 'Building docker image repo/wsl-test:latest' failed with exit code 1.
stdout:
stderr:
#1 [internal] load build definition from Dockerfile.docker
#1 sha256:ca6baf96b252c45d3972df0fa238a5047cc3a09c7bb64f871d265aa1536c2aac
#1 transferring dockerfile: 83B done
#1 DONE 0.0s
#2 [internal] load .dockerignore
#2 sha256:9ac169b8d72041de9368febed87f2d8da13c300d0215a2cc3b4150498c749505
#2 transferring context: 2B done
#2 DONE 0.0s
#3 [internal] load metadata for docker.io/library/python:3.8
#3 sha256:edad251955f644c6004999f0af04035912392fa02db26821676452becbc715fb
#3 ERROR: rpc error: code = Unknown desc = error getting credentials - err: exit status 1, out: ``
------
> [internal] load metadata for docker.io/library/python:3.8:
------
failed to solve with frontend dockerfile.v0: failed to create LLB definition: rpc error: code = Unknown desc = error getting credentials - err: exit status 1, out: ``

Use `--no-process-cleanup` to preserve process chroots for inspection.

[kaos]

OK, to hopefully get you a little bit further, if you first docker pull python:3.8 so you have that locally, it should not have to pull it again while building, and hopefully not stumble on the credentials issue.

However, at some point the credentials would be needed, so the question is what settings can be done to let docker use the correct configuration.

There's likely a configuration file for the docker client with details about the credentials/session etc that may be associated with the current user. This association may be lost when Pants invokes docker in the hermetic sandbox, so you want to restore that, I'm hoping that providing some properly set environment vars would solve that. Like DOCKER_CONFIG=C:\some\path\config perhaps.. idk.

Google is our friend here, to try to come up with how to accomplish this.

[dmder]

Not sure how sustainable this fix is, but as suggested in https://github.com/docker/for-win/issues/11261, setting

"features": {
  "buildkit": false
}

in Docker Desktop / Settings / Docker Engine solved the problem for me (running Docker Desktop 4.10.1).

[cedric-fauth]

Same problem here. Would be great to fix this because we need to disable buildkit for now which is unfavorable.

[cedric-fauth]

This problem still exists. Would be great if it can be solved, because disabling buildkit is not an option in the future.