The Package stage allows you to publish, consume and discover packages, all in one place. We believe that source code and dependencies should live in one secure environment, protected by your GitLab credentials. The efficiencies gained by centralization allow you to focus on productivity. By integrating with GitLab's CI/CD product, we can ensure efficient and reliable pipelines.
Take a look at this video for a walkthrough of the stage, north stars, and categories that make up Package:
Feel free to reach out to PM Tim Rizzi (E-Mail) if you'd like to provide feedback or ask questions about what's coming.
There are a few important north stars we are keeping sight of to guide us forward in this space. With each of these, we're focusing on complete (what we call minimally lovable) features.
Our goal is to provide a single interface for managing dependencies, registries, and package repositories. In order to achieve that goal, we must allow users to integrate with any development environment. This means we must support a wide variety of package managers and languages. We currently support Maven, NPM and Docker. We will be adding support for C++ (Conan), .net (NuGet), Linux (Debian, RPM), and Helm Charts (Kubernetes).
Package Managers such as JFrog and Sonatype make it easy to managed shared binaries. They provide improved performance by allowing users to store and cache their binaries and avoid repetitive downloading with each build. The current GitLab offering is lacking in these areas.
However as single-point solutions, they introduce extra cost and complexity. By providing a single location for the entire DevOps Lifecycle, we allow users to avoid unnecessary context switching and save money on additional licensing and maintenance fees.
In addition to supporting multiple package management clients, we must ensure that we provide a simple, unified method of authentication. GitHub does this by allowing users to authenticate with their personal access token. However, we must also provide a means of publishing, deleting and updating from CI/CD builds. Our current thinking is to allow users to authenticate using their personal access token or their CI_JOB_TOKEN.
Our initial focus has been on making dependencies accessible to ensure that sharing packages is easy. Next, we will focus on improving performance, reducing external dependencies, and giving administrators more control over their supply chains. We are actively working on improving our storage optimization features. After that, we will allow users to set limits and policies for storage usage and automatically act on those policies to reduce the cost of storage.
After handling storage optimization, we will begin to roll out the GitLab Dependency Proxy. This will minimize the number of external downloads, improve build times, and reduce the risk of 3rd party outages. First, we will focus on the Container Registry, then roll out support for our other package manager integrations, such as Maven and NPM.
Having established the dependency proxy, we will begin to offer support for whitelisting and blacklisting of external dependencies. Along with GitLab's dependency scanning product, this will allow SecOps and Compliance teams to secure and control their supply chains.
There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.
Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.
A secure and private registry for Docker images built-in to GitLab. Creating, pushing, and retrieving images works out of the box with GitLab CI/CD. This category is at the "viable" level of maturity.
Our easy to use integration of Maven provides Java developers with a standardized way to share and version control Java packages across projects. This category is at the "minimal" level of maturity.
A Rubygem registry offers ruby developers an easy to use, built-in solution to share and version control ruby gems in a standardized and controlled way. Internally provisioning sets teams up for improved features around privacy and pipeline build speeds. This category is planned, but not yet available.
Linux distros depend on linux package regisitries for distribution of installable software. By supporting Debian and RPM we will cater to a large segment of our users and allow systems administration tasks to be brought in-house. This category is planned, but not yet available.
Kubernetes cluster integrations can take advantage of Helm charts to standardize their distribution and install processes. Supporting a built-in helm chart registry allows for better, self-managed container orchestration. This category is planned, but not yet available.
Conan is an open source, decentralized and multi-platform C/C++ Package Manager for developers to create and share native binaries. This category is planned, but not yet available.
The GitLab dependency proxy can serve as an intermediary between your local developers and automation and the world of packages that need to be fetched from remote repositories. By adding a security and validation layer to a caching proxy, you can ensure reliability, accuracy, and auditability for the packages you depend on. This category is planned, but not yet available.
At GitLab, one of our values is that everyone can contribute. If you're looking to get involved with features in the Package area, there are a couple searches you can use to find issues to work on:
Contribute for Prizeprogram is available on our Code Contributor Programs page.
You can read more about our general contribution guidelines here.
It's important to call out that the below plan can change any moment and should not be taken as a hard commitment, though we do try to keep things generally stable. In general, we follow the same prioritization guidelines as the product team at large. Issues will tend to flow from having no milestone, to being added to the backlog, to being added to this page and/or a specific milestone for delivery.
There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.
Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!