diff options
Diffstat (limited to 'doc/development/packages.md')
| -rw-r--r-- | doc/development/packages.md | 53 |
1 files changed, 49 insertions, 4 deletions
diff --git a/doc/development/packages.md b/doc/development/packages.md index 6d4a9ea9f41..7ae3cd53e66 100644 --- a/doc/development/packages.md +++ b/doc/development/packages.md @@ -5,7 +5,7 @@ This document will guide you through adding another [package management system]( See already supported package types in [Packages documentation](../administration/packages/index.md) Since GitLab packages' UI is pretty generic, it is possible to add basic new -package system support by solely backend changes. This guide is superficial and does +package system support with solely backend changes. This guide is superficial and does not cover the way the code should be written. However, you can find a good example by looking at existing merge requests with Maven and NPM support: @@ -14,6 +14,28 @@ by looking at existing merge requests with Maven and NPM support: - [Maven repository](https://gitlab.com/gitlab-org/gitlab/merge_requests/6607). - [Instance level endpoint for Maven repository](https://gitlab.com/gitlab-org/gitlab/merge_requests/8757) +## Suggested contributions + +The goal of the Package group is to build a set of features that, within three years, will allow ninety percent of our customers to store all of their packages in GitLab. To do that we need to ensure that we support the below package manager formats. + +| Format | Use case | +| ------ | ------ | +| [Bower](https://gitlab.com/gitlab-org/gitlab/issues/36888) | Boost your front end development by hosting your own Bower components. | +| [Chef](https://gitlab.com/gitlab-org/gitlab/issues/36889) | Configuration management with Chef using all the benefits of a repository manager. | +| [CocoaPods](https://gitlab.com/gitlab-org/gitlab/issues/36890) | Speed up development with Xcode and CocoaPods. | +| [Conda](https://gitlab.com/gitlab-org/gitlab/issues/36891) | Secure and private local Conda repositories. | +| [CRAN](https://gitlab.com/gitlab-org/gitlab/issues/36892) | Deploy and resolve CRAN packages for the R language. | +| [Debian](https://gitlab.com/gitlab-org/gitlab/issues/5835) | Host and provision Debian packages. | +| [Go](https://gitlab.com/gitlab-org/gitlab/issues/9773) | Resolve Go dependencies from and publish your Go packages to GitLab. | +| [Opkg](https://gitlab.com/gitlab-org/gitlab/issues/36894) | Optimize your work with OpenWrt using Opkg repositories. | +| [P2](https://gitlab.com/gitlab-org/gitlab/issues/36895) | Host all your Eclipse plugins in your own GitLab P2 repository. | +| [Puppet](https://gitlab.com/gitlab-org/gitlab/issues/36897) | Configuration management meets repository management with Puppet repositories. | +| [PyPi](https://gitlab.com/gitlab-org/gitlab/issues/10483) | Host PyPi distributions. | +| [RPM](https://gitlab.com/gitlab-org/gitlab/issues/5932) | Distribute RPMs directly from GitLab. | +| [RubyGems](https://gitlab.com/gitlab-org/gitlab/issues/803) | Use GitLab to host your own gems. | +| [SBT](https://gitlab.com/gitlab-org/gitlab/issues/36898) | Resolve dependencies from and deploy build output to SBT repositories when running SBT builds. | +| [Vagrant](https://gitlab.com/gitlab-org/gitlab/issues/36899) | Securely host your Vagrant boxes in local repositories. | + ## General information The existing database model requires the following: @@ -45,6 +67,29 @@ PUT https://gitlab.com/api/v4/projects/<your_project_id>/packages/npm/ Group-level and instance-level endpoints are good to have but are optional. +### Remote hierarchy + +Packages are scoped within various levels of access, which is generally configured by setting your remote. A +remote endpoint may be set at the project level, meaning when installing packages, only packages belonging to that +project will be visible. Alternatively, a group-level endpoint may be used to allow visibility to all packages +within a given group. Lastly, an instance-level endpoint can be used to allow visibility to all packages within an +entire GitLab instance. + +Using group and project level endpoints will allow for more flexibility in package naming, however, more remotes +will have to be managed. Using instance level endpoints requires [stricter naming conventions](#naming-conventions). + +The current state of existing package registries availability is: + +| Repository Type | Project Level | Group Level | Instance Level | +|-----------------|---------------|-------------|----------------| +| Maven | Yes | Yes | Yes | +| Conan | No - [open issue](https://gitlab.com/gitlab-org/gitlab/issues/11679) | No - [open issue](https://gitlab.com/gitlab-org/gitlab/issues/11679) | Yes | +| NPM | No - [open issue](https://gitlab.com/gitlab-org/gitlab/issues/36853) | Yes | No - [open issue](https://gitlab.com/gitlab-org/gitlab/issues/36853) | + +NOTE: **Note:** NPM is currently a hybrid of the instance level and group level. +It is using the top-level group or namespace as the defining portion of the name +(for example, `@my-group-name/my-package-name`). + ## Naming conventions To avoid name conflict for instance-level endpoints you will need to define a package naming convention @@ -61,14 +106,14 @@ model for that package type. ## File uploads -File uploads should be handled by GitLab workhorse using object accelerated uploads. What this means is that +File uploads should be handled by GitLab Workhorse using object accelerated uploads. What this means is that the workhorse proxy that checks all incoming requests to GitLab will intercept the upload request, upload the file, and forward a request to the main GitLab codebase only containing the metadata and file location rather than the file itself. An overview of this process can be found in the [development documentation](uploads.md#workhorse-object-storage-acceleration). In terms of code, this means a route will need to be added to the -[gitlab-workhorse project](https://gitlab.com/gitlab-org/gitlab-workhorse) for each level of remote being added +[GitLab Workhorse project](https://gitlab.com/gitlab-org/gitlab-workhorse) for each level of remote being added (instance, group, project). [This merge request](https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/412/diffs) demonstrates adding an instance-level endpoint for Conan to workhorse. You can also see the Maven project level endpoint implemented in the same file. @@ -135,7 +180,7 @@ process. These changes represent all that is needed to deliver a minimally usable package management system. -1. Empty file structure (api file, base service for this package) +1. Empty file structure (API file, base service for this package) 1. Authentication system for 'logging in' to the package manager 1. Identify metadata and create applicable tables 1. Workhorse route for [object storage accelerated uploads](uploads.md#workhorse-object-storage-acceleration) |