Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab
GitLab
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 34,939
    • Issues 34,939
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 1,281
    • Merge Requests 1,281
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #36892

Closed
Open
Opened Nov 20, 2019 by Tim Rizzi@trizziDeveloper

CRAN Repository MVC

Problem to solve

Binary Repository Managers (https://en.wikipedia.org/wiki/Binary_repository_manager) allow easy access and management of artifacts created and consumed by projects. Software like JFrog Artifactory (https://www.jfrog.com/artifactory/) or Sonatype Nexus (https://www.sonatype.com/nexus-repository-oss) are examples of multi-protocol repositories.

We want to enhance our existing artifacts system, allowing access using the most common package managers. This issue focuses on Cran

Proposal

The MVP will focus on:

  • Cran

Intended users

  • Delaney (Development Team Lead)
  • Sasha (Software Developer)
  • Devon (DevOps Engineer)
  • Sidney (Systems Administrator)

Further details

Proposal

A list of possible MRs for any given package system:

MVP MRs (system is not useable until all are completed)

  • Empty file structure (api file, base service for this package)
  • Authentication system for 'logging in' to the package manager
  • Identify metadata and create applicable tables
  • Endpoints required for upload/publish
  • Endpoints required for install/download
  • Endpoints required for remove

Possible post-MVP MRs (system is useable, but these may be desired before releasing for general use)

  • Endpoints required for search
  • Limits on file sizes
  • Tracking for metrics
  • Support building/updating deleting packages with CI
  • Group/sub-group support
  • Instance level support

Permissions and Security

Permissions and Security

The permissions should follow the same levels as NPM, Maven and Conan.

Project Permissions: UI

Action Guest Reporter Developer Maintainer Owner
Pull from Maven, NPM, Conan, NuGet x x x x
Publish to Maven, NPM, Conan, NuGet x x x

Project Permissions: API

Action Guest Reporter Developer Maintainer Owner
List project packages (5) x x
Get a project package x x
List package files x x
Delete a project package x x

Group Permissions: API

Action Guest Reporter Developer Maintainer Owner
List the packages of a group (coming soon) x x

Instance Level Permissions

Action Guest Reporter Developer Maintainer Owner
Enable the Packages feature x
Migrate local packages to object storage x
Disable the Packages feature x

Documentation

  • GitLab Package Registry

Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Links / references

Assignee
Assign to
Awaiting further demand
Milestone
Awaiting further demand
Assign milestone
Time tracking
None
Due date
None
Reference: gitlab-org/gitlab#36892