Manifest not displayed in GHCR UI when using attestations

[LeviPesin]

There is no problem with this:

No problem

- name: Push Docker image
  uses: docker/build-push-action@2eb1c1961a95fc15694676618e422e8ba1d63825
  with:
    context: src
    tags: ${{ needs.metadata.outputs.tags }}
    labels: ${{ needs.metadata.outputs.labels }}
    cache-from: type=gha
    cache-to: type=gha,mode=max
    load: true
- name: Push Docker image to GHCR
    run: docker push -a ghcr.io/${{ inputs.image-name }}

But a problem with this:

Breaks

- name: Push Docker image
  uses: docker/build-push-action@2eb1c1961a95fc15694676618e422e8ba1d63825
  with:
    context: src
    tags: ${{ needs.metadata.outputs.tags }}
    labels: ${{ needs.metadata.outputs.labels }}
    cache-from: type=gha
    cache-to: type=gha,mode=max
    push: true

Is this a GHCR problem or a problem with the action?

Expected behaviour (First code snippet)

Actual behaviour (Second code snippet)

As you can see some weird unknown/unknown architecture appears and GHCR can no longer read labels including license and description.

Logs

First log: https://pastebin.com/xVnafXKJ
Second log: https://pastebin.com/X4yyB9gx

[crazy-max]

Seems an issue with GHCR not being able to parse an OCI index or it tries to parse manifest attestations but fails to display infos from labels. Pure speculation but I think GitHub does not check the mime-type of the manifest on their side so it fails.

Can you try disabling provenance?:

- name: Push Docker image
  uses: docker/build-push-action@2eb1c1961a95fc15694676618e422e8ba1d63825
  with:
    context: src
    tags: ${{ needs.metadata.outputs.tags }}
    labels: ${{ needs.metadata.outputs.labels }}
    cache-from: type=gha
    cache-to: type=gha,mode=max
    push: true
    provenance: false

[crazy-max]

Same as docker/setup-buildx-action#187 (comment)

[LeviPesin]

But it seems the core issue -- moby/moby#43126 -- has been fixed already?
Or is GHCR using something else that reads OCI incorrectly?

It seems to display correctly with disabled proveance indeed.

[crazy-max]

But it seems the core issue -- moby/moby#43126 -- has been fixed already?

Yes Docker tooling is fixed

Or is GHCR using something else that reads OCI incorrectly?

Maybe I don't know what GH is using internally. We had opened an internal discussion with them but no response yet. I'll keep you posted as soon as we know more.

[aaomidi]

@crazy-max have you learned more about this?

[kroese]

@aaomidi This is fixed in BuildX 0.12 but Github runners still use 0.11.2 so you will have to be patient a bit longer...

[LeviPesin]

Is there some estimation when GHCR would update to 0.12?

[kroese]

Sorry, I mixed up two issues. I thought it was about GHCR not showing the description info for images. This can be solved by setting:

env:
     DOCKER_METADATA_ANNOTATIONS_LEVELS: manifest,index

in the metadata-action config and

annotations: ${{ steps.meta.outputs.annotations }}

in the build-push-action. But it requires BuildX 0.12 so it will work as soon as Github updates the workflow runners to that version. It does not require any change to GHCR at all.

But now I see this issue was about the unknown architecture, and that does require an update of GHCR and willl not be solved by BuildX 0.12, sorry.

[raoganeshr]

@crazy-max Did GitHub come back on when will this be addressed?

For us, this problem leads to creation of 3 image entries in GHCR. One is the main image and other two are the manifest and manifest list which are untagged. We have a workflow that deletes older images with a specific tag that also deletes untagged images which in turn ends up deleting the manifests causing the image pull to fail post the cleanup.