Design an interface focused on enabling users to adding the ability to connect and setup remote and virtual repositories for their package registries.
Problem to solve
The GitLab Package Registry allows users to build, share and publish packages in a variety of formats to a private, GitLab hosted repository. However, many of our customers also rely on a variety of public package repositories as well, for example npmjs.org or nuget.org. Users need the ability to easily pull/publish packages to those remote repositories as well.
A virtual repository is a collection of local, remote and other virtual repositories accessed through a single logical URL. This hides the access details of the underlying repositories letting users work with a single, well-known URL.
In order to improve our offering, we should allow users to easily access remote repositories and create and leverage virtual repositories.
Intended users
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
Further details
Use cases
- Pull packages not found in GitLab from a remote public repository
- Define and prioritize multiple remotes for pulling packages not found in the local Gitlab registry.
- Cache packages for future use in GitLab CI/CD with the Dependency Proxy.
- Use the GitLab API to manage the cache.
- Use the GitLab application to set up and manage the Dependency Proxy.
Benefits
- Faster build times when using the cache
- More reliable builds
- Easier setup and use of GitLab's Package Registry
Instance/Group/Project Level
Each package manager format currently has a slightly different implementation with regards to instance, group and project level endpoints. We need to make a decision for which level this feature should reside and may need to prioritize work to establish new endpoints for existing integrations.
The Dependency Proxy is currently is at the group level for the following reasons:
- We have too much complexity in project itself. If we can unload some features that are necessary only on a group level, we should do it.
- Putting the feature into the same UI as a container registry is confusing for a user. You should be able to use a registry proxy even if you don't use a registry itself.
- People are likely to create one project per group and re-use it for a whole group as a single proxy endpoint.
- In future we introduce dependency proxy for maven and npm. It makes sense to have all dependency proxy features in one place in UI.
- Billing is on a group level so it can be used on GitLab.com
What does success look like, and how can we measure that?
Success looks like we empower our users with the ability to easily configure and access local, remote and virtual repositories and that this drives increased usage and adoption throughout the GitLab community.
Metrics
- Total number of community contributions to devopspackage in GitLab FOSS
- number of packages pulled from a remote repository
- number of packages cached from a remote repository
- hit rate of packages found in the cache vs. not in the cache
Future Iterations
A few ideas of what could be included or looked at in future iterations:
- In the project level package registry UI, we could show information related to the dependency proxy, including what virtual registries this registry is connected to.