podman icon indicating copy to clipboard operation
podman copied to clipboard

Additional build contexts should be sent as additional tar files

Open l0rd opened this issue 1 year ago • 4 comments

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

  • #18691
  • #18840
  • #14453
  • https://github.com/containers/buildah/pull/3978
  • https://github.com/containers/podman/pull/14320
  • https://github.com/containers/podman/issues/23429

l0rd avatar Jul 29 '24 15:07 l0rd

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.

Luap99 avatar Jul 29 '24 16:07 Luap99

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

afbjorklund avatar Jul 29 '24 16:07 afbjorklund

Seems reasonable.

rhatdan avatar Jul 30 '24 15:07 rhatdan

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")

afbjorklund avatar Jul 30 '24 15:07 afbjorklund

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

github-actions[bot] avatar Aug 30 '24 00:08 github-actions[bot]

This will be interesting in combination with: https://github.com/containers/podman/issues/26321

Honny1 avatar Jul 02 '25 15:07 Honny1