GitLab is introducing the Maven dependency proxy, a new feature that will enable enterprises to consolidate on the DevSecOps platform for artifact management. The Maven dependency proxy, available in Beta, enables larger organizations to be more efficient by expanding the functionality of GitLab's package registry. The new feature can make pipelines faster and more reliable, and can reduce the cost of data transfer since over time most packages will be pulled from the cache.
How the Maven dependency proxy works
A typical software project relies on a variety of dependencies, which we call packages. Packages can be internally built and maintained, or sourced from a public repository. Based on our user research, we’ve learned that most projects use a 50/50 mix of public vs. private packages. When installing packages, the order in which they are found and downloaded is very important, as downloading or using an incorrect package or version of a package can introduce breaking changes and security vulnerabilities into their pipelines.
The Maven dependency proxy gives users the ability to add or configure one external Java repository. Once added, when a user tries to install a Java package using their project-level endpoint, GitLab will first look for the package in the project and if it's not found, will attempt to pull the package from the external repository.
When a package is pulled from the external repository, it will be imported into the GitLab project so that the next time that particular package/version is pulled it's pulled from GitLab and not the external repository. If the external repository is having connectivity issues and the package is present in the dependency proxy, then pulling that package will work. This will make your pipelines faster and more reliable.
If the package changes in the external repository — for example, a user deletes a version and publishes a new one with different files — the dependency proxy will detect that and invalidate the package in GitLab to pull the "newer" one. This will ensure that the correct packages are downloaded and help to reduce security vulnerabilities. If the package is not found in their GitLab project or the external repository, GitLab will return an error.
Here are more details of the Maven dependency proxy:
- This feature and all future dependency proxy formats will be in the Premium tier.
- Project owners will be able to configure this feature via a project's settings (API or UI).
- We will support external repositories that require authentication, such as Artifactory or Sonatype.
A fit for the enterprise
Enterprise organizations that need to consolidate on GitLab and move away from Artifactory or Sonatype can make use of the new Maven dependency proxy. Virtual registries allow you to publish, proxy, and cache multiple package repositories behind a single, logical URL.
The Maven dependency proxy is the MVC of a set of features that will help enterprise organizations sunset their existing artifact management vendors, such as Artifactory or Sonatype Nexus, to help reduce costs and improve the developer user experience.
Roadmap
- Finish the Maven dependency proxy (Milestone 16.7)
- npm dependency proxy
- Make the dependency proxy for containers work generically with any container registry
- PyPI dependency proxy
- NuGet dependency proxy
How we will measure success
We will start to measure success by tracking adoption by tier with the following metrics:
- Number of packages pulled through the dependency proxy
- The hit ratio (packages pulled from the cache vs. upstream repository)
- Number of users that pulled a package through the dependency proxy
How to get started
In the video below, you can see a short demo of the Maven dependency proxy in action.
Prerequisites
- As of the time of writing this, the feature is behind a feature flag.
- The settings for your project must be updated using GraphQL.
Join the Beta program by adding a comment to this epic. Note: The feature is planned to go to general availability in Version 16.7 or 16.8.
