-
Notifications
You must be signed in to change notification settings - Fork 24
Description
Is your feature request related to a problem?
I'd like to have better visibility of what zot is storing.
That includes images that have been published previously and become untagged, or when OCI artifacts have been published.
Describe the solution you'd like
Versions Overview - Tagged / Untagged
Something like GHCR "Versions" view would be useful:
It provides an overview of all images associated to an image/repo (not quite familiar with the correct jargon here), allowing you to additionally filter the view by tagged or untagged and interact with the items.
However, I'm not really a fan of the UX inconsistency in presentation there when the digest has an associated tag(s).
- Not sure why the
deletebutton is missing on that one. Deletion UX in general is poor at GHCR beyond basics. - The
...is a button that toggles the visibility of the digest (and it's copy button that non-tagged digests lack).
OCI Artifacts - Referral API
GHCR presently lacks support for Referrers API, so when querying via oras discover it will fallback to Referrers tag scheme there. GHCR UI presently lacks the ability to distinguish OCI artifacts.
In the screenshot above the digests listed were all related to the same multi-arch image (linux/amd64 + linux/arm64), while two of those digests are provenance attestation artifacts for their respective platform (which Docker includes these attestations as entries in the image index as the unknown/unknown platform besides the proper amd64/arm64 platform images):
zui appears to have a view to use the Referrers API to show OCI artifacts belonging to a platform image, but it fails to show anything (perhaps it's just mocked out?):
I know this functionality works with zot as oras discover is capable of discovering the related OCI artifacts via the Referrers API.
Describe alternatives you've considered
Use an alternative container registry? I've been using ghcr.io and DockerHub, but recently tried zot with zui.
Additional context
Also note that the publish timestamp is when the digest was published / updated at the registry, not necessarily when it was built? (which seems to be what ZUI presents? I think it's using the timestamp from an image manifest configs created timestamp)
Both are useful but when I interact with an container registry I consider the timestamp to represent activity with the registry, whereas the image itself may annotate a timestamp related to it's build for inspection via a different view.


