Skip to content
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

buildx 0.10.0 seems to have changed something which leads to a different kind of manifests (at least for GCP) #187

Closed
Lawouach opened this issue Jan 20, 2023 · 21 comments

Comments

@Lawouach
Copy link

Behaviour

Steps to reproduce this issue

  1. Create a build with buildx v0.9.1 and push it to GCP container registry (or even their new artefact registry)
  2. Use said image from Cloud Run => it works
  3. Do the same with v0.10.0 and it now fails to be deployed by Cloud Run

Expected behaviour

Either version should work.

Actual behaviour

What I could notice is that, with v0.9.1 we get a single image with a single manifest. With the newer version, it looks like we have three images and a different manifest,. Two of the images are actually empty.

with v0.9.1

{
   "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
   "schemaVersion": 2,
   "config": {
      "mediaType": "application/vnd.docker.container.image.v1+json",
      "digest": "sha256:02dc4c100ef625d2dc5b40499b076a86648d58b05968214a228868966c04cd47",
      "size": 4445
   },
   "layers": [
      {
         "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
         "digest": "sha256:3f701d9643d37eca8cb445ba978c767bc1e07bf958e94504db0298999bfe58c1",
         "size": 27478988
      },
      {
         "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
         "digest": "sha256:5359441c5fbe3749694e1aa16b863c2f51af7b2860919abfc226754102cdabfd",
         "size": 15815598
      },
      {
         "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
         "digest": "sha256:75c4a9d4d7ef0593255452f2ec0a848a59c17d60b2fe862e0d57e748e8cec377",
         "size": 1677
      },
      {
         "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
         "digest": "sha256:b67de70bba634431f53729f10b75ac2385b21c9d970c0a48734ff9a2798ee171",
         "size": 26863764
      },
      {
         "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
         "digest": "sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1",
         "size": 32
      },
      {
         "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
         "digest": "sha256:aa1b41bbbf18f17dd7bc8b55ba7048e96d3c855d70c3d928f2d62f5ea4959171",
         "size": 229
      }
   ]
}

with v0.10.0

{
   "mediaType": "application/vnd.oci.image.index.v1+json",
   "schemaVersion": 2,
   "manifests": [
      {
         "mediaType": "application/vnd.oci.image.manifest.v1+json",
         "digest": "sha256:640eb44cbf9bc53054086d68131f4345138085b0b37d061a812c07c922dbf76c",
         "size": 1432,
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.oci.image.manifest.v1+json",
         "digest": "sha256:752970a0a4550a28f85a0a49530c38e787394f2f10884712816814e3932fc71e",
         "size": 566,
         "annotations": {
            "vnd.docker.reference.digest": "sha256:640eb44cbf9bc53054086d68131f4345138085b0b37d061a812c07c922dbf76c",
            "vnd.docker.reference.type": "attestation-manifest"
         },
         "platform": {
            "architecture": "unknown",
            "os": "unknown"
         }
      }
   ]
}

My guess is that there is no actual bug with buildx or your action, but GCP cannot handle the different kind of manifest. But I wondered if your action should/could expose a flag that allows using the newer version but keep the old manifest?

@Lawouach
Copy link
Author

For now, the workaround is to pin to v0.9.1

@tonistiigi
Copy link
Member

it now fails to be deployed by Cloud Run

What fails and what error?

it looks like we have three images

?

This is new provenance attestation feature. You can disable it by setting --provenance false, but the image you are showing is a valid OCI image, and there should be no issues with pushing or pulling it.

@Lawouach
Copy link
Author

Thank you for the update. I must admit I have not dug very deeply into new formats so I appreciate the guidance indeed.

and there should be no issues with pushing or pulling it.

That's exactly the problem however. Cloud Run complains the image doesn't exist (not the tag, the image itself). When I can happily pull it with docker directly indeed.

@azrshana
Copy link

azrshana commented Jan 20, 2023

We have just hit this issue as well. With v0.9.1, buildx build application/vnd.docker.distribution.manifest.v2+json images, and starting with v10.0, it started building application/vnd.oci.image.index.v1+json by default. This causes Cloud Run to say that the image is not found and to fail. We have also reverted to using version v0.9.1 to resolve the issue.

Could we understand where this default behavior for buildx is documented and how we may pin the image type to application/vnd.docker.distribution.manifest.v2+json` while still using v.10.0+.

Workaround:

 - name: Setup buildx
        uses: docker/setup-buildx-action@v1
        with:
          install: true
          version: v0.9.1

@sylr
Copy link

sylr commented Jan 20, 2023

Have the same problem with ghcr.io, docker manifest inspect did not work on new images generated with latest buildx. Also they appeared weirdly on github.

v0.9.1:
SCR-20230120-f9x

v0.10.0:
SCR-20230120-fd2

@jedevc
Copy link
Contributor

jedevc commented Jan 20, 2023

👋 Thanks for the bug reports! Very much appreciated, thanks for taking the time!


@Lawouach @azrshana I've opened a separate tracking issue for the GCR failure - docker/buildx#1533. There's not a lot we can really do about this one - buildkit is producing spec-compliant images in this case, cloud run is just not really doing anything with them 😢

As a temporary workaround, instead of pinning to a lower buildx version (once pinned, things often stay pinned 👀), I can recommend setting --provenance=false on the buildx cli, or provenance: false if using the docker/build-push-action. This will disable the attestation that's causing that change to the multi-platform image.


@sylr docker manifest unfortunately doesn't support OCI images - we're tracking this docker/buildx#1509. We hadn't realized how much buildx and docker manifest were being used together - as a workaround until we can get support for docker manifest to support OCI images, you might be interested in using buildx imagetools - there's some more detail in the linked issue.

cc @crazy-max do you know about the GitHub manifest display issue? I remember we discussed previously.


I'm gonna close this issue, we can track each component separately 🎉 If there's anything I missed, please shout ❤️

@jedevc jedevc closed this as completed Jan 20, 2023
@Lawouach
Copy link
Author

Thanks @jedevc for the swift care for this one and I appreciate the advice. I'll try.

@sylr
Copy link

sylr commented Jan 20, 2023

For the record I used docker manifest inspect in my deployment pipelines to be sure I'm not about to deploy an helm release with versions of a docker images that haven't been pushed to the registry yet.

@pantelis-karamolegkos
Copy link

pantelis-karamolegkos commented Jan 24, 2023

Facing a similar error in GCR even with

      - name: set up docker buildx
        id: setup-buildx
        uses: docker/setup-buildx-action@v2.2.1
        with:
          version: v0.9.1
          driver-opts: network=host

and

      - name: build and push to local registry
        uses: docker/build-push-action@v3.3.0
        with:
          context: ${{ inputs.context }}
          file: ${{ inputs.context }}/${{ inputs.dockerfile }}
          no-cache: ${{ inputs.no_cache }}
          build-args: ${{ inputs.build_args }}
          push: true
          tags: ${{ env.LOCAL_IMAGE }}
          builder: ${{ steps.setup-buildx.outputs.name }}
          provenance: false
          sbom: false
          attests: ""

Could the issue be related to BuildKit? I see that it using 0.11 no matter the buildx version I am using.

@pantelis-karamolegkos
Copy link

pantelis-karamolegkos commented Jan 24, 2023

Is there a way to set the BuildKit version as an action input?
No matter the action version I pin, BuildKit is always 0.11

zachhannum added a commit to rstudio/checkrs-tew that referenced this issue Feb 14, 2023
This commit updates some of the docker action dependencies
to fix issues related to the latest versions of buildx.

- Updates docker/setup-buildx-action to v2
- Updates docker/build-push-action to v4
- Adds the `provenance: false` property to build-push-action
  to fix issue with multi-arch builds. See
  docker/setup-buildx-action#187
zachhannum added a commit to rstudio/checkrs-tew that referenced this issue Feb 14, 2023
This commit updates some of the docker action dependencies
to fix issues related to the latest versions of buildx.

- Updates docker/setup-buildx-action to v2
- Updates docker/build-push-action to v4
- Adds the `provenance: false` property to build-push-action
  to fix issue with multi-arch builds. See
  docker/setup-buildx-action#187
@majidakbaridh
Copy link

Is there any way to use newer version of setup-buildx-action but changing mediaType to "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json" ?

@Geczy
Copy link

Geczy commented Dec 28, 2023

this is still an issue in 2024

@majidakbaridh
Copy link

Is there any way to use newer version of setup-buildx-action but changing mediaType to "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json" ?

I found the solution, as mentioned in other comments, you need to set the provenance: false, however the point is that you need to change it in build-push-action action not this setup-buildx-action one.

@Geczy
Copy link

Geczy commented Dec 28, 2023

image

i almost had it working but the docker buildx shit was ruining the manifest, see left. correct is on the right side

i tried everything to make it do a better manifest but idk how

like

  - name: Build and push
    uses: docker/bake-action@v4
    with:
      push: true
      sbom: false
      provenance: false
      set: |
        *.output=type=docker,oci-mediatypes=false
        *.platform=linux/arm64

after docker buildx push

➜ ~ docker pull ghcr.io/dotabod/steam:v2.2
v2.2: Pulling from dotabod/steam
manifest unknown

vs docker compose push

➜ ~ docker pull ghcr.io/dotabod/steam:v2.2
v2.2: Pulling from dotabod/steam
1207c741d8c9: Pulling fs layer
854bbbc098b2: Pulling fs layer
d30ccb81ed57: Pulling fs layer
74a11634af6c: Waiting
e68101b738c0: Waiting

I even tried 0.9.1
dotabod/backend@e2b88ea

This is the main trials
https://github.com/dotabod/backend/blob/abb6c688de712ac8d94c30da13ee67c1590c79de/.github/workflows/builder.yml

You can see x bake here also

https://github.com/dotabod/backend/blob/abb6c688de712ac8d94c30da13ee67c1590c79de/docker-compose.yml

How do I fix this manifest while still using the action buildx since it gives me caching abilities

@majidakbaridh
Copy link

build-push-action

image

i almost had it working but the docker buildx shit was ruining the manifest, see left. correct is on the right side

i tried everything to make it do a better manifest but idk how

like

  - name: Build and push
    uses: docker/bake-action@v4
    with:
      push: true
      sbom: false
      provenance: false
      set: |
        *.output=type=docker,oci-mediatypes=false
        *.platform=linux/arm64

after docker buildx push

➜ ~ docker pull ghcr.io/dotabod/steam:v2.2 v2.2: Pulling from dotabod/steam manifest unknown

vs docker compose push

➜ ~ docker pull ghcr.io/dotabod/steam:v2.2 v2.2: Pulling from dotabod/steam 1207c741d8c9: Pulling fs layer 854bbbc098b2: Pulling fs layer d30ccb81ed57: Pulling fs layer 74a11634af6c: Waiting e68101b738c0: Waiting

I even tried 0.9.1 dotabod/backend@e2b88ea

This is the main trials https://github.com/dotabod/backend/blob/abb6c688de712ac8d94c30da13ee67c1590c79de/.github/workflows/builder.yml

You can see x bake here also

https://github.com/dotabod/backend/blob/abb6c688de712ac8d94c30da13ee67c1590c79de/docker-compose.yml

How do I fix this manifest while still using the action buildx since it gives me caching abilities

The explained method is working with build-push-action action. However you are using bake-action action.

@sudo-bmitch
Copy link

@Geczy it looks like you are storing the cache to the same tag as the output image. Try using a different tag for the cache output.

@Geczy
Copy link

Geczy commented Dec 28, 2023

Build push action doesn't work for me because I'm using a docker compose file. Do I need to use build push action and call it once for every service I have and also convert my compose yml into the dockerfile just to get this working?

@Geczy
Copy link

Geczy commented Dec 28, 2023

@Geczy it looks like you are storing the cache to the same tag as the output image. Try using a different tag for the cache output.

Thanks I'll give that a shot

@Geczy
Copy link

Geczy commented Dec 28, 2023

@sudo-bmitch caching looks to be working now, and the manifest looks good too, but it doesn't seem to update my package with the new build even though i made a file change that caused it to rebuild

CleanShot 2023-12-28 at 09 54 18@2x

https://github.com/dotabod/backend/actions/runs/7348686262/job/20007250704

any ideas what else i can try?

@sudo-bmitch
Copy link

@Geczy The output type=docker will push the result to the local docker engine. If you want it pushed to the registry, use type=registry or type=image,push=true. https://docs.docker.com/engine/reference/commandline/buildx_build/#output

@Geczy
Copy link

Geczy commented Dec 28, 2023

wow all my issues i spent a day on are solved now! tysm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants