## Context So far, we're relying on the Docker/OCI [Listing Image Tags](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md#listing-image-tags) registry API to list tags and display them in the GitLab: - [List registry repository tags API](https://docs.gitlab.com/ee/api/container_registry.html#list-registry-repository-tags) - [Get details of a single repository API](https://docs.gitlab.com/ee/api/container_registry.html#get-details-of-a-single-repository) (when the `tags` and/or `tags_count` parameter is set to `true`) - [Get details of a registry repository tag API](https://docs.gitlab.com/ee/api/container_registry.html#get-details-of-a-registry-repository-tag) - [Tags list UI](https://gitlab.com/gitlab-org/build/CNG/container_registry/3968339) ## Problems ### Performance Using this API is a performance problem because in most cases, it requires doing `1+3N` network requests against the registry, where `N` is the number of tags on each GitLab UI/API tags list page: 1. List tags (just their name) within the repository 1. For each tag: 1. `HEAD` tag to get the corresponding manifest digest 1. `GET` corresponding manifest payload 1. `GET` corresponding configuration payload (to infer the creation timestamp from it) ### Accuracy One of the most important pieces of information about tags in the GitLab UI/API is the published timestamp. However, in the current implementation, the timestamp shown is not actually the time at which an image tag was pushed/published but rather the image build-time timestamp. Why? The Docker/OCI API did not provide any means to track tag publish timestamps, so the only possible workaround was to look at the image configuration payload assembled by the container runtime when _building_ (not pushing!) the image and extract the creation timestamp from that. As result, the shown timestamp will not change when e.g. re-tagging an existing image. Apart from the above, not all tools used to build container images will fill the creation timestamp in the configuration payload. As result, we can face situations where there is no timestamp to show on the UI, and this leads to https://gitlab.com/gitlab-org/gitlab/-/issues/300380. ## Solution We have recently introduced a new registry [list repository tags API](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/api.md#list-repository-tags). This was not possible to achieve before https://gitlab.com/groups/gitlab-org/-/epics/5523. Since then, we've been gradually replacing the use of the old Docker/OCI tags list API with this new API. The latest was for cleanup policies in https://gitlab.com/groups/gitlab-org/-/epics/8379, which resulted in a major performance (and accuracy) improvement. We can continue to do this work by using the new API when listing tags in the GitLab UI. Right now, this UI looks as follows:  We can replace the `1+3N` requests against the registry with a single one, and get an accurate publish timestamp AND major performance improvement for free. The only missing piece of information that is needed for the GitLab UI/API and that is not yet part of the [registry API response](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/api.md#body-1) is: - Manifest digest - Configuration digest We should be able to add these to the response without much trouble. ### Required Changes 1. Expand the registry [list repository tags API](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/api.md#list-repository-tags) so that it includes the manifest and configuration digest for each one of the listed tags gitlab~8033085 ~backend 1. Update the Rails backend so that it uses the above when populating the response for the `getContainerRepositoryTags` GraphQL query used by the frontend gitlab~25806308 ~backend: - We must guarantee backward compatibility with self-managed, where this new registry API is not yet available. In those cases, we should continue to perform the current requests against the registry Docker/OCI API; - The `CreatedAt` field in the response must be populated based on the `created_at` and `updated_at` timestamps from the registry response, as discussed [here](https://gitlab.com/gitlab-org/gitlab/-/issues/351031#note_1084564139); No ~frontend changes should be required.