As part of our overall vision for packaging at GitLab, we want to provide a single interface for managing dependencies, registries, and package repositories. Whether C/C++, Java, Ruby, or any other language, our vision is that you can store your binaries and dependencies in the GitLab Package Registry. There are a few key package/language types on our radar that we want to support as part of this category:
Because there are many great solutions out there in the market for package registries, our plan is to provide a single, consistent interface to whichever package manager you're using. We want you to be able to take advantage of the great features each of these tools offer, but at the same time, we want there to be a consistent experience that's well integated with the rest of your workflow at GitLab.
Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
Next up on our agenda is to implement gitlab-ee#8248, the MVC for the GitLab Conan Repository, which will provide a base feature for users to start integrating with and providing feedback.
We are also continuing to improve our existing NPM and Maven integrations. For Maven, gitlab-ee#9947 will add support for pulling dependencies at the sub-group level. For NPM, gitlab-ee#9104 will allow users to authenticate with
CI_JOB_TOKEN and help streamline publishing packages via GitLab CI. Finally, gitlab-ee#10003 will expand the packages API to allow users to list all packages of all projects within a given group in a single list.
This category is currently at the "Minimal" maturity level, and our next maturity target is "Viable" (see our definitions of maturity levels). Key deliverables to achieve this are:
☑️ indicates support is through community plugin or beta feature
Historically, we've provided access to the GitLab container registry for free, but limited access to package registries to our paid tier. However, with GitHub's annoucement to support a package registry for free, we are re-evaluating this strategy.
A lot of moving our vision forward is integrating MVC support for new languages and package types:
Our vision begins with implementing the gitlab-ee#8248, which will allow us to kick off support. Beyond the initial MVC implementation, our focus will be on improving consistency and core features across all of our repository types rather than providing C/C++ specific features. This may change as we begin to get customer feedback from real-world users of the new repository.
For .NET, the Microsoft-supported mechanism for sharing code is NuGet, which defines how packages for .NET are created, hosted, and consumed, and provides the tools for each of those roles. By integrating with NuGet, GitLab will provide a centralized location to store and view those packages, in the same place as their source code and pipelines. gitlab-ce#39794 details the first steps in adding NuGet support to the GitLab Package Registry.
gitlab-ee#803 which will add support for a RubyGem registry.
gitlab-ee#9993 details the need to track which underlying packages a release incorporates and detail any changes in those underlying dependencies. Although not specific to Helm charts, this functionality represents a leap forward in our current offering.