Skip to content

Plan use of the new container registry tags list API to display tags in the GitLab UI/API

Context

Part of &10208 (closed). Please read its description for context.

The frontend tags list UI is making use of the getContainerRepositoryTags GraphQL operation to obtain the list of tags to present. Internally, the rails backend is 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 (source)
  2. For each tag:
    1. HEAD tag to get the corresponding manifest digest (source)
    2. GET corresponding manifest payload (source)
    3. GET corresponding configuration payload (to infer the creation timestamp from it) (source)

The same flow is followed for the Get details of a registry repository tag API.

With the new registry list repository tags API, only available on GitLab.com, we can replace these 1+3N requests against the registry with a single one.

At the time of writing, the attributes needed for the getContainerRepositoryTags GraphQL / Get details of a registry repository tag REST API response are already included in the new registry list repository tags API, except:

Apart from the above, the CreatedAt/created_at field of the GraphQL/REST API response must be filled based on the created_at and updated_at attributes already present on the registry API response (rational).

It's important to note that this new API is only available on GitLab.com, thus, we must guarantee compatibility with self-managed, which means that somewhere in the codebase (as high as possible in the call stack) we must do something like the following when processing these GraphQL/REST API requests:

if Gitlab.com?
  # proceed with the new method
else
  # proceed in the old way
end

Implementation

The purpose of this issue is to create a detailed implementation plan to use of the new container registry tags list API to display tags in the GitLab UI/API.

Edited by João Pereira