Investigate adding support for RubyGems to the GitLab Package Registry
Release post
If you are a GitLab user building a Rails app, you need to be able to publish your gems to a private repository, share them and install them from a safe location. Why not use your GitLab project? You are already storing your code there and you are probably using GitLab CI. It's easy to publish and install packages using your pipeline. In fact, if you are using GitLab CI/CD to publish and update your gems, you can easily find the pipeline, commit and branch responsible for updating that gem. Authentication is easy. Simply use your personal access token. With support for job and deploy tokens coming soon.
Problem to solve
As part of our goal to build a product that in 3 years will allow 90% of our customers to use GitLab for all of their package management needs, we must add support for common package manager formats, such as RubyGems. Prior to adding support for a given package manager, we need to have a task of investigation of documentation, API endpoints, and other implementation requirements.
This issue is intended to detail the requirements for the RubyGems Repository MVC and link to issues outside the scope of the MVC. It will be considered complete when the product developers have broken down the MVC into sub-issues and added them to the RubyGems Repository epic.
Proposal
Investigate adding RubyGems support to the GitLab Package Registry. Based on that investigation, identify a reasonable MVC that can be delivered in 1-2 milestones.
- Create, size and schedule a list of sub-issues and add them to the epic
Scope of MVC
- Use your GitLab project as a RubyGems remote
- Authenticate with your GitLab personal access token
- Publish gems to your project
- Install gems from your project
- Measure
push_package
andpull_package
events on GitLab.com using Snowplow
Beyond the MVC
- Measure usage with the usage ping
- The Package Registry UI supports RubyGems, including install and setup commands, build and package specific metadata.
- Authenticate with a job, deploy, or project access token.
- Create a
.gitlab-ci.yml
template to make getting started easy. - Begin dogfooding the registry
- Starting in RubyGems 2.0, a Specification can hold arbitrary metadata. We should consider supporting arbitrary metadata.
Metadata
Metadata will need to be extracted, similar to how we handle NuGet. For the MVC we will extract the following fields:
- authors=
- files
- name
- summary
- version
- description
- homepage
- license=
- licenses=
- metadata
After the MVC, we'll add:
- add_development_dependency
- add_runtime_dependency
- author=
- bindir
- cert_chain
- executables
- extensions
- extra_rdoc_files
- platform=
- post_install_message
- rdoc_options
- require_paths=
- required_ruby_version
- required_ruby_version=
- required_rubygems_version
- required_rubygems_version=
- requirements
- rubygems_version
- signing_key
Permissions and Security
The permissions should follow the same levels as all other package registries