Additional build contexts should be sent as additional tar files

[l0rd]

Feature request description

Option --build-context <label>=<context-path> of the podman build command allows to specify additional build contexts. The podman client doesn't send these additional build contexts as tar files in the current implementation. Only the main build context is sent.

Since podman doesn't send the build contexts to the remote machine, and only passes its local path as an API parameter, the build usually fails because the context path doesn't exist in the remote machine. It only works in the cases where the build context path is mounted, on the same path, in the remote machine. But in the general case, it doesn't.

Suggest potential solution

A reasonable way to resolve the problem is to transfer every additional build context as a tar file. And change the build HTTP request content to be multi-part. However, we should investigate how Docker handles that, as it's not part of the core engine API (additional build contexts are a buildx feature). So, we should look at how a Docker client handles it and work on a compatible solution.

Have you considered any alternatives?

On Windows and macOS the problem is mitigated by mounting, in the remote machine, $HOME and other system folders. But if the user overrides the default machine mounts, the machine is in a remote machine etc...the podman build command will still fail.

Additional context

• Issues with VSCode Dev Containers Compatibility  #18691
• Multiple build context fails on Windows #18840
• remote: enable support for additional --build-context on macOS and remote #14453
• buildkit, build: add support for additionalBuildContext in builds via --build-context buildah#3978
• build: allow using cache explicitly with --squash-all using --layers  #14320
• Error running podman build with option --build-context on Hyper-V #23429

[Luap99]

So, we should look at how a Docker client handles it and work on a compatible solution.

AFAIK buildkit/buildx uses a reverse API where they turn the client into a server and then the actual remote server just asks the client for the files it needs. Which well is much better as only files actually needed are transferred but ff course this is much more complex and requires many API changes. And AFAIK they use some grpc client so this is anything but simple.

[afbjorklund]

You can use the docker-buildx standalone program with Podman (using DOCKER_HOST)

Then it will support all the buildx features. Maybe this can be an option* in podman buildx?

* similar to docker-compose vs. podman-compose

PODMAN_BUILDX_PROVIDER=docker-buildx

[rhatdan]

Seems reasonable.

[afbjorklund]

It would still be nice to fix the feature in buildah (podman build), so it is more of a workaround.

The only implementation detail would be that buildx needs a --load or a --output type=oci |

---

WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load

It works fine to save the output into a file, or to pipe it straight into podman load (more explicit)

• https://github.com/moby/buildkit#containerizing-buildkit

• https://github.com/moby/buildkit#output ("OCI tarball")

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[Honny1]

This will be interesting in combination with: #26321