[BUG] Bake build fails when using BAKE_CMD_CONTEXT locally

[nVlast]

I noticed that when I use the BAKE_CMD_CONTEXT built-in variable in a local HCL bake file, the build fails.

Steps to reproduce:

1. Create a Dockerfile (named "Dockerfile"):

FROM alpine
CMD ["sleep", "infinity"]

2. Create a bake file (named "docker-bake.hcl"):

target "default" {
  dockerfile = "Dockerfile"
  context = BAKE_CMD_CONTEXT
  tags = ["myimage:myversion"]
}

3. Run docker buildx bake

Expected outcome:
The docker image specified should be built

Actual outcome:

ERROR: could not find cwd:: stat cwd:: no such file or directory

---

I looked into it a bit further, and it seems that when the aforementioned built-in variable was introduced, while the context was arranged to be "cleaned" from the cwd protocol, the dockerfilePath is left with a cwd reference in it. Perhaps something as simple as adding a !strings.HasPrefix(contextPath, "cwd://") check here would be sufficient but take that with a pinch of salt as I'm not all that familiar with the codebase.

Also, if this variable was never meant to work in a local setting, please close this issue.

[crazy-max]

@nVlast Yes BAKE_CMD_CONTEXT has to be used with a remote definition as shown here: https://docs.docker.com/build/bake/file-definition/#remote-definition but it should not fail for local builds.

I'm able to repro locally but --print gives the expected value for context:

$ docker buildx bake --print
{
  "target": {
    "default": {
      "context": ".",
      "dockerfile": "Dockerfile",
      "tags": [
        "myimage:myversion"
      ]
    }
  }
}

Will take a look, thanks for your feedback.

[socheatsok78]

I encounter similar error when I tried to build using "Remote definition" as shown in the docs.

• macOS 12.6.4
• Docker Desktop 4.17.0

docker buildx bake "https://github.com/tonistiigi/buildx.git#remote-test" --print

#1 [internal] load git source https://github.com/tonistiigi/buildx.git#remote-test
#1 0.900 577303add004dd7efeb13434d69ea030d35f7888	refs/heads/remote-test
#1 CACHED
ERROR: Rel: can't make . relative to /path-to-project

And when loading from SSH remote.

docker buildx bake "git@github.com:tonistiigi/buildx.git#remote-test" --print
#1 [internal] load git source git@github.com:tonistiigi/buildx.git#remote-test
#0 0.056 Initialized empty Git repository in /var/lib/buildkit/runc-overlayfs/snapshots/snapshots/73/fs/
#1 ERROR: Unimplemented: unknown service moby.sshforward.v1.SSH
------
 > [internal] load git source git@github.com:tonistiigi/buildx.git#remote-test:
#0 0.056 Initialized empty Git repository in /var/lib/buildkit/runc-overlayfs/snapshots/snapshots/73/fs/
------
ERROR: failed to find target default

Updates

I found out if it set the env BAKE_ALLOW_REMOTE_FS_ACCESS=true the command docker buildx bake "https://github.com/tonistiigi/buildx.git#remote-test" --print run without any errors.

buildx/bake/bake.go

Line 950 in 1e149bb

if v, ok := os.LookupEnv("BAKE_ALLOW_REMOTE_FS_ACCESS"); ok {

Updates 2

By tracing the function call, this is the call that produce the ERROR: Rel: can't make . relative to /path-to-project

buildx/bake/bake.go

Lines 986 to 989 in 1e149bb

	rel, err := filepath.Rel(wd, p)
	if err != nil {
	return err
	}

[c-ameron]

Hi @crazy-max , do you know if this will be fixed in the next release? It would be a huge help for my use case of sourcing a fixed set of remote docker instructions, but using the local build context.
Thanks! 😃

[jedevc]

@nVlast @c-ameron sorry this missed getting added to the v0.11.0 release, but I'll try and get it cherry-picked into v0.11.1, since it's a pretty small change.

@socheatsok78 your Rel: can't make . relative to /path-to-project looks like #1840, which was in the v0.11.0 release.