Support exposing the Go modules of a project under the packages of another project
Background
Go uses a source-based dependency management system, whereas most other dependency management systems are artifact-based. This is to say, Go dependencies are ultimately fetched directly from their source VCS repository, but dependencies in other systems are artifacts that have been uploaded to a package repository. Another unique feature of the Go ecosystem is the name of a package (excluding stdlib) must be a valid URL, sans the scheme (e.g. golang.org/x/text). Thus, Go modules are defined by the source repository and have unique names.
Problem to solve
GitLab's Go module support expects that module gitlab.com/my/project is defined by the repository https://gitlab.com/my/project.git. This matches the expectations of the Go tool chain and ecosystem. However, could be quite useful to be able to expose modules defined by https://gitlab.com/my/project.git as 'packages' of some other project, e.g. https://gitlab.com/my/gopkgs.
GitLab's Go module support should be expanded to include this use case. Exposing the modules of gitlab.com/a/b as 'packages' of gitlab.com/x/y should involve a manual configuration action (e.g. clicking a button) and the user executing this action must have appropriate permissions on both projects.
Intended users
Further details
TODO
Proposal
Essentially, I propose some mechanism that allows the user to assert that the Go modules of one project should be accessible from the Go modules proxy, Packages API, and Packages UI of another project.
Permissions and Security
Creating or removing this association between two projects should require the user have the appropriate permissions on each project. For the source project, this includes permission to clone the repo, and may also include permission to read packages. For the project that the modules will be accessible from, this may include permission to read, create, and destroy packages.
Documentation
- user/packages/go_proxy/index.md
- development/packages.md
- api/packages.md
Availability & Testing
TODO
What does success look like, and how can we measure that?
The modules of a source project, which has been linked to a second project as above:
- Can be fetched from the Go module proxy of the second project, pending !27746 (merged)
- Are included in response from the Package API and in the Package UI, pending #213770 (closed)
What is the type of buyer?
- Individual Contributor
- Manager
The director or executive may care if this is used as a way to distribute packages to customers. This is less likely to happen with Go modules, since the Go module proxy distributes source, not binaries.
Is this a cross-stage feature?
Not sure.