Skip to content

Rubygems Package Manager MVC

Release post

For any organization delivering software, providing teams with an easy and secure way to manage dependencies is critical. Package managers, such as RubyGems, provide a standardized way to share and version-control these libraries across projects.

We are proud to offer support for publishing Ruby packages directly into GitLab. Developers now have an easier way to publish their projects’ gems. All you have to do is set the RubyGems remote to the GitLab Package Registry and start uploading, installing, and deleting packages today.

Problem to solve

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. In order to achieve that goal, we must provide support for the most commonly used package managers for our users. T

Ruby developers need a mechanism to create, share, and consume packages that contain compiled code and other content in projects that consume these packages.

Proposal

Provide support for users coding in Ruby/Rails by integrating with RubyGems and allowing developers to publish, share, and consume packages alongside their source code and CI/CD pipelines.

Proposed MVC Scope

  • We will provide documentation for, configuring the client to add GitLab to the remote list.
  • Users are able to authenticate using their GitLab credentials
  • Users are able to push a package
  • Users are able to pull a package
  • Users are able to delete a package (for the MVC, we will only allow deletion via the Packages API or the UI)

Further details

Investigation results

📄 Summary

Implementing the RubyGems package registry combines a variety of the behavior's we have seen in previously implemented package managers (metadata extraction, index creation, authentication potentially using a secondary JWT). Because we are familiar with these patterns, we can work from pre-established code. RubyGems Gem module is also written in ruby and available to help with some of the operations we need to perform.

🔎 Issue breakdown

Each item represents 1 MR, we can create an issue for each, or keep things like "Upload" combined in one issue with many MRs.

  1. API skeleton with feature flag

  2. Authentication

    GET /api/v4/projects/27/packages/gems/api/v1/api_key

  3. Workhorse route

  4. Upload

    1. Metadata model, table, factories, fixtures

    2. Dependency services

    3. Metadata extraction services and jobs

    4. Package and package file creation services

    5. Upload routes

      POST /api/v4/projects/27/packages/gems/api/v1/gems
POST /api/v4/projects/27/packages/gems/api/v1/gems/authorize

  5. Install

    1. Spec file generation

    2. Spec file download routes

      GET "/api/v4/projects/27/packages/gems/specs.4.8.gz"
GET "/api/v4/projects/27/packages/gems/latest_specs.4.8.gz"
GET "/api/v4/projects/27/packages/gems/specs.4.8.gz"

    3. Dependencies route

      GET "/api/v4/projects/27/packages/gems/api/v1/dependencies"

    4. Versions route

      GET "/api/v4/projects/27/packages/gems/versions"

    5. Gemspec download route

      GET "/api/v4/projects/27/packages/gems/quick/Marshal.4.8/test_gem-1.0.0.gemspec.rz

    6. Gem download route

      GET "/api/v4/projects/27/packages/gems/gems/test_gem-1.0.0.gem"

  6. Remove feature flag

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
  • email
  • 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

Links

Testing

An end-to-end test for this package manager is scheduled gitlab-org/quality/testcases#1131 (closed) the coverage should be similar to package managers already in the Package QA test suite epic

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by 🤖 GitLab Bot 🤖