You need to sign in or sign up before continuing.

Add an instance-level endpoint to the Go module proxy

Followup to #27376 (closed), !27746 (merged)

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

An instance-level Go proxy endpoint should be added to ee/lib/api/go_proxy.rb, to allow all Go modules in a GitLab instance to be fetched from a single endpoint. Currently, the Go module proxy (MVC) only has a project-level endpoint. Given how Go is configured, this requires an entry in GOPROXY (an environment variable) for each project. #213900 (closed) would simplify this to one per group, but an instance-level endpoint would simplify even further.

Additionally this would allow configuration of the Go module proxy on an instance-wide basis.

Intended users

Further details

TODO

Proposal

ee/lib/api/go_proxy.rb currently exposes an API at /projects/:id/packages/go/*module_name/@v/.... Another should be added at /packages/go/*module_name/@v/...

Given that Go module names are always a URL, and given that the current implementation* only exposes modules that match the project they are contained in, namespace collisions are not a concern.

#213761 (closed) would allow a project to host modules that use an external URL. It would also require validation that the URL directs Go to that project. This should prevent any collisions between external 'vanity URLs'.

Permissions and Security

The logic for resolving a Go module to a GitLab project is straightforward. From there, the existing validation that checks if the authenticated user is authorized to view the modules of the project should suffice.

Documentation

administration/packages/index.md
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?

There is an instance-level endpoint that conforms to the Go module proxy specification (see go help goproxy) that exposes the Go modules of all projects on the instance.