Skip to content

Use the list tags repository API to fetch tags in GraphQL

🌅 What does this MR do and why?

Closes Use the list repository tags API and its pagina... (#411387 - closed)

The list repository tags API has recently added support for the pagination that GraphQL has. You may see the documentation for the API here .

In this MR, we want to use the list repository tags API through GitlabAPIClient#tags to fetch, filter, sort, and paginate the tags for the GraphQL resolver ContainerRepositoryTagsResolver. With this change, we improve performance by only doing one API call and letting the API do the sorting and filtering.

We are putting this change behind a feature flag and this only applies to migrated repositories (i.e. and now only Gitlab.com is migrated to the metadata database).

🖼 Screenshots

The page for container registry repositories would load the same before and after the changes. Screenshot_2023-10-03_at_08.49.45

The page where tags are listed are also the same: Screenshot_2023-10-03_at_08.50.04

The page should also work the same way, sorting, filtering, and pagination work the same way.

The following screenshots the difference in the pagination with and without the changes.

🐠 Before the update (i.e. with the feature flag off or when the container repository is not migrated)

If we inspect the Network in the browser, we can see that the pagination cursors are something that GraphQL has generated.

Screenshot_2023-10-03_at_08.51.06

🐟 After the update (i.e. with the feature flag on and when on the container repository is migrated)

When the page loads, this is the response. We can see that the endCursor is set to tag6.

Screenshot_2023-10-03_at_10.39.29

And that is because the last tag in our page is tag6:

Screenshot_2023-10-03_at_10.44.17

And when clicking the Next button, we see the pagination parameters. These parameters are from the list tags repository API.

Screenshot_2023-10-03_at_10.40.29

💻 How to set up and validate locally

🎢 Setup and Preparation:

This change is behind a feature flag and also a ContainerRepository#migrated? check. This is false locally so we can setup and make it true for the mean time.

In app/models/container_repository.rb, we add true to #migrated?:

  def migrated?
    true || Gitlab.com_except_jh?
  end

🙌 Common steps for before/after:

Note: Make sure you have done the preparation step above 😊

  1. Head over to the Container Registry page:

Screenshot_2023-10-03_at_16.33.53

  1. Choose a project with container repository tags (the more the better so you can test out the pagination).

Screenshot_2023-10-03_at_08.49.45

  1. Click on the project and you will now see the tags page:

Screenshot_2023-10-03_at_08.50.04

🍉 Testing the current flow:

Do Steps 1-3 above in Common steps for before/after.

  1. Disable the feature flag: use_repository_list_tags_on_graphql
Feature.disable(:use_repository_list_tags_on_graphql)
  1. Refresh the tags page

  2. Check the network tab and find the graphql request. Observe the cursor given. Try to sort, filter by name, and test the pagination and observe the cursor as you go.

Screenshot_2023-10-03_at_08.51.06

This cursor is generated by GraphQL.

🍎 Testing the updated flow:

Do Steps 1-3 above in Common steps for before/after.

  1. Enable the feature flag: use_repository_list_tags_on_graphql
Feature.enable(:use_repository_list_tags_on_graphql)
  1. Refresh the tags page.

  2. Check the network tab and find the graphql request. Observe the cursor given. Try to sort, filter by name, and test the pagination and observe the cursor as you go.

Screenshot_2023-10-03_at_10.39.29

The cursors that you see are tag names and are the cursors from the API.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #411387 (closed)

Edited by Adie (she/her)

Merge request reports