<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=36892) </details> <!--IssueSummary end--> ### 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](https://cran.r-project.org/) ### Proposal The MVP will focus on: * [Cran](https://cran.r-project.org/) ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### 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)](https://gitlab.com/gitlab-org/gitlab-ee/issues/10003) | | | | 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](https://docs.gitlab.com/ee/user/packages/) ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Links / references