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.
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.
See an up-to-date roadmap.
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.
We track epics for many of the major deliverables associated with these north stars, you can view them on a calendar at this link.
Developers rely on a variety of language-specific package manager clients to access, build and publish packages. Our vision is to provide a universal package manager, one that integrates with the most commonly used clients and makes them accessible in a single, shared location. Success is defined by our ability to not only support a wide variety of package manager clients, but to provide a consistent, delightful user experience with each integration. We currently support Maven, NPM and Docker. We will be adding support for C++ (Conan), .net (NuGet), Linux (Debian, RPM), and Helm charts (Kubernetes).
As we roll out support for additional package management clients, we must ensure that we provide a secure, unified method of authentication. Our vision is to allow users to leverage their personal access token for authenticating with any of the GitLab package repositories. In order to support managing dependencies from CI/CD builds, we will also support authenticating with CI_JOB_TOKEN
Developers rely on an ever-growing list of external, 3rd party dependencies. Each of those dependencies must be downloaded, stored, and updated as part of the software development lifecycle. Our vision is to provide users a reliable, performant location for downloading, caching and managing all of their external dependencies.
We are actively working on improving our storage optimization features, which will allow administrators to better track usage, set limits, and establish policies to reduce the overall cost of storage of the GitLab Package Registry. We will continue to roll out the GitLab Dependency Proxy to a broader audience. This will minimize the number of external downloads, improve build times, and reduce the risk of 3rd party outages.
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.
Every team needs a place to store their packages and dependencies. GitLab aims to provide a comprehensive solution, integrated into our single application, that supports package management for all commonly used languages and binary formats. This category is at the "minimal" level of maturity.
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.
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.
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 at the "minimal" level of maturity.
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!