You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using podman build --build-context=name=/path/to/build/context doesn't work with podman remote. Current podman implementation do expect /path/to/build/context to be on the machine where podman server is running, while users do expect it to be on the machine where the podman client is (like the "root" build context containing the containerfile which is on the client machine).
Since here it's really a podman related issue, not a buildah one, I open this on podman side. The expected behavior would be that the client would create a tarball from the additional build context, send it to libpod via the HTTP API, and on server side podman would extract it in a temporary location, then call buildah with the temporary location.
Steps to reproduce the issue
Steps to reproduce the issue
Start a recent podman server in one container, using a shared volume to share the socket with a different podman container later:
> podman run -t -i --rm --pull=always --privileged --name=podman-server -v /shared-volume quay.io/podman/upstream podman system service -t 0 unix:///shared-volume/podman.sock
Start a second podman client container, sharing the podman socket from the above podman server
> podman run -t -i --rm --pull=always --volumes-from podman-server quay.io/podman/upstream
Inside the client podman container, setup a root build context and an additional build context, then try to build the containerfile:
[root@5b39f9cc2200 /]# mkdir /root-client-build-context
[root@5b39f9cc2200 /]# cat > /root-client-build-context/Dockerfile <<EOF
> FROM fedora
> COPY --from=additional-build-context some-file /some-file
> EOF
[root@5b39f9cc2200 /]# mkdir /additional-client-build-context
[root@5b39f9cc2200 /]# echo "some-content" > /additional-client-build-context/some-file
[root@5b39f9cc2200 /]# podman --url=unix:///shared-volume/podman.sock build --build-context=additional-build-context=/additional-client-build-context /root-client-build-context
STEP 1/2: FROM fedora
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob sha256:df63d833bf8ab7742db9db42b6c4cacb17442b2098f88d1c261ea92e4902d7c7
Copying config sha256:e60768e94c327170a04782ff819590500d00bcb3a1eff830278b911a3bd90237
Writing manifest to image destination
STEP 2/2: COPY --from=additional-build-context some-file /some-file
Error: building at STEP "COPY --from=additional-build-context some-file /some-file": checking on sources under "/additional-client-build-context": error in copier subprocess: changing to intended-new-root directory "/additional-client-build-context": chdir /additional-client-build-context: no such file or directory
(Note: if creating the /additional-client-build-context resources in the podman server container, "podman build" works).
Describe the results you received
The image build fails, as podman server wrongly expect the additional build context to be on the server side.
Describe the results you expected
The image should work, using the build context from the client machine.
podman info output
Reproduced using the latest `quay.io/podman/upstream` image.
Podman in a container
No
Privileged Or Rootless
None
Upstream Latest Release
Yes
Additional environment details
No response
Additional information
No response
The text was updated successfully, but these errors were encountered:
I don't think this is expected to work, there simply is no API to do this with the service. We would have to completely reinvent a new build API that would allow sending more than one build context which I do not see happening.
Note the this limitation is documented so this isn't a bug
Valid values are:
Local directory – e.g. --build-context project2=../path/to/project2/src (This option is not available with the remote Podman client. On Podman machine setup (i.e macOS and Windows) path must exists on the machine VM)
Issue Description
Using
podman build --build-context=name=/path/to/build/context
doesn't work with podman remote. Current podman implementation do expect/path/to/build/context
to be on the machine where podman server is running, while users do expect it to be on the machine where the podman client is (like the "root" build context containing the containerfile which is on the client machine).Since here it's really a podman related issue, not a buildah one, I open this on podman side. The expected behavior would be that the client would create a tarball from the additional build context, send it to libpod via the HTTP API, and on server side podman would extract it in a temporary location, then call buildah with the temporary location.
Steps to reproduce the issue
Steps to reproduce the issue
(Note: if creating the
/additional-client-build-context
resources in the podman server container, "podman build" works).Describe the results you received
The image build fails, as podman server wrongly expect the additional build context to be on the server side.
Describe the results you expected
The image should work, using the build context from the client machine.
podman info output
Reproduced using the latest `quay.io/podman/upstream` image.
Podman in a container
No
Privileged Or Rootless
None
Upstream Latest Release
Yes
Additional environment details
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: