-
Notifications
You must be signed in to change notification settings - Fork 481
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
docker manifest
does not work with output from buildx v0.10
#1509
Comments
Since buildx 0.10, a minimal provenance attestation is also pushed (
But don't think
If you disable provenance it should work:
|
Copying my workaround suggestions from another issue:
|
If I use imagetools instead of default one, how can I use |
To merge manifests using |
Looks related to moby/moby#43126 👀 |
Hi 👋 I'd like to use When Additionally, Leaving this here as suggested in docker/build-push-action#764 |
docker manifest
does not work with output from buildx v0.11
docker manifest
does not work with output from buildx v0.11docker manifest
does not work with output from buildx v0.10
workaround for docker/buildx#1509 and moby/moby#43126
hoping it gets fixed upstream ref docker/buildx#1509 (comment)
Docker recently introduced [provenance attestation](https://docs.docker.com/build/attestations/slsa-provenance/) in buildx 0.10.0, which broke our multi-arch image builds. By default, `docker buildx build` now defaults to `--provenance true` which causes even single-architecture images to be built as a manifest list (aka multi-arch image consisting of one architecture, according to this GitHub issue [comment](docker/buildx#1509 (comment))). When we use our older manifest-tool to create a manifest from three single-arch images (amd64, arm32v7, and arm64v8), the tool fails because it can't create a manifest list that points to other manifest lists. To mitigate, we'll disable provenance attestation for now. In the future we should look at updating how we create our multi-arch images. To test, I ran the CI build and end-to-end tests to confirm the images build successfully and function as expected. ## Azure IoT Edge PR checklist:
Workaround to opt-out of unsupported manifest until it's supported. Fix is from: docker/buildx#1509 (comment) Watchtower autoupdater should work again: containrrr/watchtower#1529
Docker recently introduced [provenance attestation](https://docs.docker.com/build/attestations/slsa-provenance/) in buildx 0.10.0, which broke our multi-arch image builds. By default, `docker buildx build` now defaults to `--provenance true` which causes even single-architecture images to be built as a manifest list (aka multi-arch image consisting of one architecture, according to this GitHub issue [comment](docker/buildx#1509 (comment))). When we use our older manifest-tool to create a manifest from three single-arch images (amd64, arm32v7, and arm64v8), the tool fails because it can't create a manifest list that points to other manifest lists. To mitigate, we'll disable provenance attestation for now. In the future we should look at updating how we create our multi-arch images. To test, I ran the CI build and end-to-end tests to confirm the images build successfully and function as expected. ## Azure IoT Edge PR checklist:
… manifests ### What changes were proposed in this pull request? This is found during Apache Spark 3.3.2 docker image publishing. It's not an Apache Spark but important for `docker-image-tool.sh` to provide backward compatibility during cross-building. This PR targets for all **future releases**, Apache Spark 3.4.0/3.3.3/3.2.4. ### Why are the changes needed? Docker `buildx` v0.10.0 publishes OCI Manifests by default which is not supported by `docker manifest` command like the following. docker/buildx#1509 ``` $ docker manifest inspect apache/spark:v3.3.2 no such manifest: docker.io/apache/spark:v3.3.2 ``` Note that the published images are working on both AMD64/ARM64 machines, but `docker manifest` cannot be used. For example, we cannot create `latest` tag. ### Does this PR introduce _any_ user-facing change? This will fix the regression of Docker `buildx`. ### How was this patch tested? Manually builds the multi-arch image and check `manifest`. ``` $ docker manifest inspect apache/spark:v3.3.2 { "schemaVersion": 2, "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json", "manifests": [ { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "size": 3444, "digest": "sha256:30ae5023fc384ae3b68d2fb83adde44b1ece05f926cfceecac44204cdc9e79cb", "platform": { "architecture": "amd64", "os": "linux" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "size": 3444, "digest": "sha256:aac13b5b5a681aefa91036d2acae91d30a743c2e78087c6df79af4de46a16e1b", "platform": { "architecture": "arm64", "os": "linux" } } ] } ``` Closes apache#40051 from dongjoon-hyun/SPARK-42462. Authored-by: Dongjoon Hyun <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]> (cherry picked from commit 2ac70ae) Signed-off-by: Dongjoon Hyun <[email protected]>
… manifests ### What changes were proposed in this pull request? This is found during Apache Spark 3.3.2 docker image publishing. It's not an Apache Spark but important for `docker-image-tool.sh` to provide backward compatibility during cross-building. This PR targets for all **future releases**, Apache Spark 3.4.0/3.3.3/3.2.4. ### Why are the changes needed? Docker `buildx` v0.10.0 publishes OCI Manifests by default which is not supported by `docker manifest` command like the following. docker/buildx#1509 ``` $ docker manifest inspect apache/spark:v3.3.2 no such manifest: docker.io/apache/spark:v3.3.2 ``` Note that the published images are working on both AMD64/ARM64 machines, but `docker manifest` cannot be used. For example, we cannot create `latest` tag. ### Does this PR introduce _any_ user-facing change? This will fix the regression of Docker `buildx`. ### How was this patch tested? Manually builds the multi-arch image and check `manifest`. ``` $ docker manifest inspect apache/spark:v3.3.2 { "schemaVersion": 2, "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json", "manifests": [ { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "size": 3444, "digest": "sha256:30ae5023fc384ae3b68d2fb83adde44b1ece05f926cfceecac44204cdc9e79cb", "platform": { "architecture": "amd64", "os": "linux" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "size": 3444, "digest": "sha256:aac13b5b5a681aefa91036d2acae91d30a743c2e78087c6df79af4de46a16e1b", "platform": { "architecture": "arm64", "os": "linux" } } ] } ``` Closes apache#40051 from dongjoon-hyun/SPARK-42462. Authored-by: Dongjoon Hyun <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]> (cherry picked from commit 2ac70ae) Signed-off-by: Dongjoon Hyun <[email protected]>
When trying to use the docker image built by the pipeline for lambda it fails with this error The image manifest or layer media type for the source image 305686791668.dkr.ecr.ap-southeast-2.amazonaws.com/auto-scheduler:main-e3745b8 is not supported. this always happens on the main branch for some reason as it was not encountered with the test tag but nevertheless here is the issue on github: docker/buildx#1509 (comment) exercism/github-actions#113
Reference docker/buildx#1509 Signed-off-by: Thomas Citharel <[email protected]>
This is causing failure to combine the multi-arch images. See docker/buildx#1509 for discussion Signed-off-by: David Porter <[email protected]>
This is causing failure to combine the multi-arch images. See docker/buildx#1509 for discussion Signed-off-by: David Porter <[email protected]>
How to reproduce:
$ uname -a
Darwin xxxxxx 21.6.0 Darwin Kernel Version 21.6.0: Thu Sep 29 20:13:46 PDT 2022; root:xnu-8020.240.7~1/RELEASE_ARM64_T8101 arm64
$ docker buildx version
github.com/docker/buildx v0.10.0 8764628
$ docker buildx create --driver=docker-container --name=buildkit-builder --use
$ docker buildx inspect --bootstrap
$ docker buildx ls
$docker buildx build -t yourname/test:2-arm64 --platform=linux/arm64 --push .
$ docker manifest inspect yourname/test:2-arm64
no such manifest: docker.io/yourname/test:2-arm64
The text was updated successfully, but these errors were encountered: