Skip to content

Investigate: How to add integrate with Google Artifact Registry

Context

In 16.0, GitLab announced the end of support for third-party container registries. This feature allowed self-managed customers to configure their GitLab instance to use an external registry, like Google Artifact Registry with GitLab.

The reasons for the end of support are documented here: #199117

Problem to solve

After announcing that deprecation I was flooded with customer concerns and questions. People were concerned that they were going to lose the ability to use a non-GitLab Container Registry.

That made me wonder. Is there something we can do to help users that are using an external container registry, especially if they are using both the GitLab container registry and an external registry?

As a result, we opened https://gitlab.com/gitlab-org/ux-research/-/issues/2602 to hear more about how customers are using GitLab and other cloud platform container registries.

Proposal

Investigate the possibility of third-party integration with Google Artifact Registry, particularly the container registry. It would be helpful to know the risks and implementation plan to allow users to:

Configure GitLab to connect to Google Artifact Registry.

  • On the left sidebar, at the top, select Search GitLab () to find your project.
  • Select Settings > Integrations.
  • Select Google Artifact Registry.
  • Under Enable integration, select the Active checkbox.
  • Provide the Artifact configuration information:
  • Artifact Registry URL: The base URL of Artifact Registry which is being linked to this GitLab project.
  • Username: Your username in GCP
  • Password: Password of your username.
  • Select Save changes.

Create environment variables to reduce friction in authentication

After the Artifact Registry integration is activated create global variables for Artifact Registry username, host, password, and URL. The variables are for CI/CD use.

View container images from Artifact Registry using the GitLab UI/API.

  • Reporter+ can view container images and tags in the container registry UI and API
  • Images/tags from Google Artifact Registry cannot be deleted from GitLab
  • Display critical (at least what we have in the GitLab UI) metadata associated with AR images/tags

Beyond the MVC

When considering the metadata associated with an artifact, we should also consider:

  • Attestations
  • Vulnerabilities associated with a tag
  • Usage data?

Questions

  • Permissions: I propose limiting the functionality to project Maintainers/Owners only. Why? Looking at the permissions, https://docs.gitlab.com/ee/user/permissions.html, like Maintainers/Owners only can adjust the project settings and add users.
  • Project/Group/Instance level: What would be most useful is to have a global setting that can be configured and applied to all projects. But still allow it to be configured at the project level to override the instance level.

Motivation

The Alliances team is considering a partnership with GCP in FY25 Q1. The results of this investigation will help to set expectations and define timelines.

What we learned from user research

  • Teams use GitLab for building, testing, and securing code and deploying to GCP and Artifact Registry due to reasons like hosting, scalability, and reliability.
  • Custom scripts used to deploy artifacts from GitLab to Google require maintenance, and there is a need for more efficient and secure methods to manage environment variables.
  • Context switching between GitLab and GCP causes inefficiencies, and there is an opportunity to provide a shared view of the registry to enhance efficiency and security awareness.
Edited by Tim Rizzi