The following page contains information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Many projects depend on a growing number of packages that must be fetched from external sources with each build. This slows down build times and introduces availability issues into the supply chain. For organizations, this presents a critical problem. By providing a mechanism for storing and accessing external packages, we enable faster and more reliable builds.
Our vision for the Dependency Proxy is to provide a product that will provide fast, reliable access to all of your dependencies, whether they are hosted on GitLab or any other vendor. In addition, the Dependency Proxy will work hand-in-hand with the planned Dependency Firewall, which will help to prevent any unknown or unverified providers from introducing potential security vulnerabilities.
Currently the Dependency Proxy allows you to proxy and cache images from DockerHub. This can help you to speed up your pipelines and reduce your external dependencies. However this is only the first step. In the coming milestones, we will expand the Dependency Proxy from a single, hardcoded endpoint, to the place where you can setup and manage all of your registries (both packages and images) in one place.
There are a few important terms that are worth sharing:
Our current plan is to:
This page is maintained by the Product Manager for Package, Tim Rizzi (E-mail)
The below diagram demonstrates how you can use the Dependency Proxy to create a virtual registry which will look for and fetch dependencies from your hosted and remote registries. This will allow you to download all of your dependencies with a single URL, instead of having to remember which packages are hosted where.
Note: The above diagram shows all of your dependencies being resolved through the Dependency Proxy. Usage of this feature is not required. You can easily use your hosted and remote registries without grouping them in a virtual registry.
Since Docker Hub has announced their new rate limiting policies we've seen increased interest in the GitLab Contanier Registry and Dependency Proxy. To prepare for this influx of users, we plan on improving the Dependency Proxy's integration with Docker Hub. There are three key issues scheduled for the next few miletsones.
This category is currently at the "Viable" maturity level, and our next maturity target is Complete (see our definitions of maturity levels).
For a list of key deliverables and expected outcomes, check out the epic, gitlab-#2920, which includes links and expected timing for each issue.
Artifactory is the leader in this category. They offer 'remote repositories' which serve as a caching repository for various package manager integrations. Utilizing the command line, API or a user interface, a user may create policies and control caching and proxying behavior. A Docker image or package may be requested from a remote repository on demand and if no content is available it will be fetched and cached according to the user's policies. In addition, they offer support for many of major packaging formats in use today. For storage optimization, they offer check-sum based storage, deduplication, copying, moving and deletion of files.
The below tables outline our current capabilities compared to JFrog's Artifactory and Sonatype's Nexus.
|Virtual registries||Coming soon||✔️||✔️|
*The Dependency Proxy currently supports one hardcoded remote registry, which allows you to proxy and cache container images hosted on DockerHub.
|Virtual registries||Coming soon||✔️||✔️|
The top customer success issue is gitlab-#11582, which will introduce authentication and allow users to leverage the Dependency Proxy with private projects.
The top internal customer issue is gitlab-#496 which will update Gitlab.com to use the Dependency Proxy for caching frequently used images from DockerHub.
Our top vision item is the epic gitlab-#2614, which will expand the Dependency Proxy to work with the GitLab Packages. Once implemented, Admin will be able to create remote and virtual registries, so that they can resolve all of their Group's dependencies with a single, logical URL.
Our plan is to start with Maven, then move on to NPM, NuGet, and PyPI.