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 working to improve our NPM integration. gitlab-ee#9960 will allow users to authenticate and pull packages at the sub-group level. Speaking of authentication, gilab-ce#63438 will add support for OAuth2 to the GitLab personal access token and gitlab-ee#9140 will allow users to to authenticate to their NPM registry using their GitLab personal access token.
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.
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.