Open LeviPesin opened 1 year ago
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
But it seems the core issue -- https://github.com/moby/moby/issues/43126 -- has been fixed already? Or is GHCR using something else that reads OCI incorrectly?
It seems to display correctly with disabled proveance indeed.
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.
@crazy-max have you learned more about this?
@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...
Is there some estimation when GHCR would update to 0.12?
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.
@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.
There is no problem with this:
No problem
But a problem with this:
Breaks
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