MVC: Integrate with Conan C/C++ Package Manager
Problem to solve
Conan is an open source C/C++ package manager that was designed to help developers create and share their binaries. By integrating with Conan, GitLab will provide a centralized location to store and view those binaries, in the same place as their source code and pipelines.
As a C/C++ developer, when I am creating, fetching or updating packages, I need a shared and secure environment to upload and view those packages, so that I can work collaboratively and efficiently with my team.
- We must allow and provide documentation for configuring Conan to add GitLab to the remote list.
- We must allow the user to authenticate with their personal access token, or CI_JOB_TOKEN
- Developers need the ability to create and upload packages to the GitLab remote
- All users (Reporter and up) need the ability to view their packages
- Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha
- Devon, DevOps Engineer, https://design.gitlab.com/research/personas#persona-devon
- Administrators can turn on/off the Conan Registry
- Administrators can configure their package manager integrations, including Conan, to update the storage path, use object storage and migrate local packages to object storage.
- Developers coding in C/C++ and using Conan can add GitLab to their Conan remote list.
- Developers can authenticate with their personal access token or CI_JOB_TOKEN.
- Developers can configure their Conan integration to work on the project, group or instance level.
- Developers can use Conan to create, modify and upload their packages to GitLab.
- Users with access to a given project can view and pull packages from the GitLab Package Registry
- Users can view basic meta data about packages from within the GitLab UI. (Name, Version, Type, Created (date))
- Users can click on a package to view additional details about it. For example, package name, version and created date. In addition, other Conan meta data, such as; OS, architecture, build type, compiler, compiler version, compiler.libcxx, shared (true/false)
- Developers can delete packages from within the GitLab UI.
This issue will contribute to the vision of the GitLab Package stage to provide a single interface for managing dependencies, registries, and package repositories.
I propose we solve this problem by integrating with Conan to allow for the better support our users that are coding in C++.
As an MVC, we can limit the scope in several ways. First, we can focus first on Instance level, similar to how we implemented Maven. Based on customer feedback, instance level is the top priority. We can also limit the scope by limiting authentication to personal access tokens and create a separate issue for supporting CI_JOB_TOKEN.
The user interface can be exactly what we have now for Maven and NPM. The only change would be slightly different meta data, when drilling into each package. And if we are limited in our ability to change that, I can limit the fields to 3 to match our current design patterns.
The permissions should follow the same levels as NPM and Maven. At the instance level, any user can view and download packages. But, only developers with permission to the project can upload and delete them.
The critical functionality Conan commands that impact us our:
conan remoteManages the remote list and the package recipes associated to a remote.
conan uploadUploads a recipe and binary packages to a remote.
conan infoGets information about the dependency graph of a recipe
conan searchSearches package recipes and binaries in the local cache or in a remote.
Permissions and Security
We will use the same permissions for the Conan Registry as we do for the NPM and Maven registries.
|Pull from Maven repository or NPM registry or Conan Registry||x||x||x||x|
|Publish to Maven repository or NPM registry or Conan Registry||x||x||x|
- We will need added to the docs at https://docs.gitlab.com/ee/user/project/packages/conan_registry.html that details how to enable, authenticate, and configure Conan to work with GitLab.
- We will need to ensure we add the Conan Registry to the packages administration docs here.
We will have to test the core functionality works:
- Feature is only available for premium/gold users
- Documentation is updated and accurate
- Users can publish packages to GitLab
- Packages show up accurately in the UI
- UI functions as expected
- No degradation in functionality in our Maven, NPM or Container registries
- Ability to connect to object storage
What does success look like, and how can we measure that?
Since this feature is being requested by several customers, our first success metric will be working with those customers to get started using the GitLab Conan Registry. Adoption of the feature will be our first key success metric.
As a metric, we could look at the
total # of eligible users / # of actual users. To start, we can limit the scope of that to the customers that have requested this feature. We can also conduct user research to discover why the feature has or has not been adopted.
What is the type of buyer?
This feature will be focused on Director and Executives, as it is a Premium/Ultimate feature. https://about.gitlab.com/handbook/ceo/pricing/#four-tiers
Links / references
- Conan docs
- Conan center JFrog partnered with Conan to create a docker hub similar product for Conan packages
- JFrog's Conan integration