-
-
Notifications
You must be signed in to change notification settings - Fork 627
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues with buildx #20189
Comments
Hi, thanks for reporting. Just to confirm, is the Also, please include the git sha of your source version, as |
Git SHA is 7e15e5c I am using the default value for type. I am not using a multi-platform build afaik; I am using a multi-stage build where the stages are separate docker_image targets. |
👍🏽
✅
yea, I mis-read that for a split second.. just picked up the |
How do you stitch multiple Do you see the |
I have 2 targets,
And then docker/prod/Dockerfile starts with
I am not super clear on how pants stitches these together or what the terminology is if not a multi-stage build. And yes, I do see the relevant image when I run |
OK, I'm not sure what's up with buildx here. Perhaps @riisi have more insights? Regarding what Pants does, it simply chains multiple docker builds, something ~eq. to:
and the "magic" here is the build arg |
I would have thought when you are using the I'm wondering if this is a more general problem with fetching/pushing to GCP - have you tried building and pushing a single image? After you build ( What do you have in |
This is actually separate from my attempts to use caching. Here is my toml file:
And yes, as noted in my first post, I see the image when I run I have read that buildx has it's own cache, but I have been unable to figure out how to inspect it. To be clear, my main concern here is not whether I can build the image or not, but what the provenance of the image is when I have my credentials configured correctly and whether it will unnecessarily read things from the network when it already has the image locally. |
You may need to enable the containerd image store (although actually that may be needed for multiplatform builds only). Running with the Pants option
|
I see pants running this command:
Which reproduces the error when I run it from the sandbox. When I remove the buildx fragment, it builds fine despite auth errors. After a bit more googling it seems like this is "expected" for buildx: moby/moby#42893 Presumably this means it requires a dependency on a repository, though it does make me a bit concerned that the build depends on what is on a remote service and has potential race conditions if someone else writes to the same tag. |
Enabling the containerd image store did not help, but also seems like a hack around the nonhermetic nature of buildx. |
Wondering if there's a solution to this by using Pants to generate a deterministic hash in the tag. |
I think a deterministic hash tag would be great. Showing these tags in build output and providing a way to access them in other build commands would also be great if possible (e.g. a shell target to start a container). I have not dug too deep into what pants already supports here with git hashes etc, but I do want to get to a workflow where multiple people can build, publish & run containers without tripping over each other and not needing to manually edit tags in a repo. |
I think you pasted the wrong link for the deterministic hashes? It feels like it should be the standard though? Having builds be nonhermetic, even when the underlying fault is with docker feels like a footgun. |
Fixed. Yes, I agree it would be nice to have a default (or even some recommendations) to avoid this. |
regarding a stable hash, see the |
Based on the extensive discussion on this issue here. I think this can potentially be solved by either a) aliasing the upstream image in the build context of the downstream image to point to a local image or b) setting the value of the build arg in pants to the address of the local image directly. I'm going to set aside some time either today or tomorrow to experiment with this and prove out that this works. |
Okay so I did some exploration here - unfortunately I was unable to get something working. Buildx drivers other than the default docker driver are totally unable to pull images from the local image store, they can only pull images from a registry. There is a solution here though, which is to use |
Confirmed that bake works pretty nicely! |
@ndellosa95 I've looked into the issue with multiple dependent images and was able to get it working using the Containerd Image Store. Here's what I've used to test this locally (M2 Mac): # BUILD
docker_image(
name="base",
source="Dockerfile.base",
cache_to={"type": "local", "dest": "/tmp/docker/pants-test-cache"},
cache_from={"type": "local", "src": "/tmp/docker/pants-test-cache"},
build_platform=["linux/amd64" ,"linux/arm64"],
)
docker_image(
name="final",
source="Dockerfile.final",
cache_to={"type": "local", "dest": "/tmp/docker/pants-test-cache"},
cache_from={"type": "local", "src": "/tmp/docker/pants-test-cache"},
build_platform=["linux/amd64", "linux/arm64"],
) # Dockerfile.base
FROM python:3.8
RUN echo "base image" >> base.txt # Dockerfile.final
ARG PARENT=:base
FROM ${PARENT}
RUN cat base.txt && \
echo "final image" >> final.txt # pants.toml (relevant config only)
[GLOBAL]
pants_version = "2.19.0rc3"
[docker]
use_buildx=true
# (Note that I didn't need to map any env vars) Enable the containerd image store - either using Docker Desktop or by setting Docker Engine config via {
"features": {
"containerd-snapshotter": true
}
} Switch to the default "docker" build driver (e.g., do not use Note I ran into this issue on my machine causing the error I was also able to test this successfully with Github Actions. @ndellosa95 Would you be able to check if this helps with your use case? I'm going to put in a PR to update the docs to suggest this as the recommended approach. The containerd image store is in beta but as far as I can see has been stable for a while and there are no obvious limitations I can see. Here is a PR to update the example-docker repo. |
Closing this as I believe it's fixed since 2.19 with above approach - let me know otherwise. |
Describe the bug
I am trying to use the new buildx features from source.
I have a multi-stage build with a docker_image target that builds on top of a base target.
With the regular builder, things work fine, but with the buildx builder, I am running into this error today:
The error here is probably unrelated to pants, docker is failing to pull this image from a remote repo, however docker should not need to pull this image since it exists locally because it was just built by pants:
When I disable buildx, my build works fine.
Pants version
From source on main
OS
Ubuntu via WSL
The text was updated successfully, but these errors were encountered: