You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using Zot Registry to host our private Docker registry used mainly in our CI. We build images using Docker Buildx with --cache-from and --cache-to parameters set to registry.
Docker Buildx pull and push build cache from/to the registry and it breaks the UI. When I try to open an image with cache in registry it doesn't open because the request fails with the same error you can see in the logs below.
Zot Regsitry also logs these lines in a loop:
zot | {"level":"warn","mediatype":"application/vnd.oci.image.layer.v1.tar+gzip","goroutine":667,"caller":"zotregistry.dev/zot/pkg/storage/common/common.go:520","time":"2024-10-15T19:00:19.649733557Z","message":"unknown media-type"}
zot | {"level":"warn","mediatype":"application/vnd.oci.image.layer.v1.tar+gzip","goroutine":667,"caller":"zotregistry.dev/zot/pkg/storage/common/common.go:520","time":"2024-10-15T19:00:19.649817397Z","message":"unknown media-type"}
zot | {"level":"warn","mediatype":"application/vnd.oci.image.layer.v1.tar+gzip","goroutine":667,"caller":"zotregistry.dev/zot/pkg/storage/common/common.go:520","time":"2024-10-15T19:00:19.649900038Z","message":"unknown media-type"}
zot | {"level":"warn","mediatype":"application/vnd.buildkit.cacheconfig.v0","goroutine":667,"caller":"zotregistry.dev/zot/pkg/storage/common/common.go:520","time":"2024-10-15T19:00:19.650578642Z","message":"unknown media-type"}
Seems like these media types are not part of the OCI spec but the spec also doesn't forbid them. Is there anything that can be done in Zot Registry to allow Docker Buildx cache to work without issues described above? Are you open to solving these issues?
Client tool used
Docker Buildx with --cache-from=type=registry,ref=$CI_REGISTRY_IMAGE_CACHE_TAG and --cache-to=type=registry,ref=$CI_REGISTRY_IMAGE_CACHE_TAG,mode=max
Seen error: Described above in the log output.
Expected behavior
I would expect registry to allow these cache images. To show them in UI and to not repeat log lines described above.
Screenshots
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
I don't think this is related to issues you mention. Docker Buildx is using OCI media types by default and I am able to successfully push and pull images to/from the Zot registry.
From what I can tell the issue is in the Registry cache storage backend and the format is uses when pushing the cache to registry even though it is using OCI media types.
zot version
v2.1.1
Describe the bug
We are using Zot Registry to host our private Docker registry used mainly in our CI. We build images using Docker Buildx with
--cache-from
and--cache-to
parameters set to registry.Docker Buildx pull and push build cache from/to the registry and it breaks the UI. When I try to open an image with cache in registry it doesn't open because the request fails with the same error you can see in the logs below.
Zot Regsitry also logs these lines in a loop:
Seems like these media types are not part of the OCI spec but the spec also doesn't forbid them. Is there anything that can be done in Zot Registry to allow Docker Buildx cache to work without issues described above? Are you open to solving these issues?
Here are some discussions about Docker Buildx cache manifests:
moby/buildkit#2220
docker/buildx#173
opencontainers/distribution-spec#290
To reproduce
Configuration
Installed Docker with Docker Buildx
Client tool used
Docker Buildx with
--cache-from=type=registry,ref=$CI_REGISTRY_IMAGE_CACHE_TAG
and--cache-to=type=registry,ref=$CI_REGISTRY_IMAGE_CACHE_TAG,mode=max
Seen error: Described above in the log output.
Expected behavior
I would expect registry to allow these cache images. To show them in UI and to not repeat log lines described above.
Screenshots
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: