Use a Go proxy for pulling Go modules
Problem to solve
Go developers need a way to proxy Go modules from public projects that define modules (i.e. contain one or more go.mod files).
Background
In the simplest form, a Go modules/package manager is a Go proxy. Without a Go proxy, modules are fetched directly from the VCS (git). A Go proxy is an interface between go and the VCS that serves as an index of modules and their versions, as a cache to reduce traffic, and as a security layer providing immutability guarantees and filtering of sources.
The Go programming language introduced Go modules starting in version 1.11, and in the recently released version 1.14, it's now considered ready for production use. This feature is intended to make dependency version information explicit and easier to manage. Modules allow you to maintain multiple versions of related Go packages. It was introduced to formalize code sharing between Go projects similar to formats like Maven and pm.
The go.mod file defines a module path and lists its dependency requirements. This file can be found in a module root directory.
- generated after initialization (go mod init [module]).
- specifies dependencies and their exact versions.
Providing a go.mod file with the correct list of requirements is the recommended way to achieve reproducible builds.
Intended users
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
Further details
Proposal
Implement a Go Proxy, which will allow Go developers to specify a specific endpoint (starting at the project-level) to fetch their Go dependencies.
MVC
- Proxy public projects that define modules (i.e. contain one or more go.mod files)
Requests
- https://docs.gomods.io/intro/protocol/
- Requests will be of the form
/api/v4/:endpoint/:module/@v/:resource
. - For
go.mod
at the root ofmy/project
, the module will bemy/project
. - For
sub/go.mod
inmy/project
, the module will bemy/project/sub
. - For example,
sub/go.mod
inmy/project
ongitlab.example.com
using a global endpoint, requests will begitlab.example.com/api/v4/packages/go/my/project/sub/@v/:resource
.
Beyond the MVC
- Support Group-level modules #213900
- Support Instance-level modules #213902 (closed)
-
Proxy projects requiring authentication (golang/go#26232).Included in !27746 (merged) - Proxy projects that do not define any modules? #213907
- Show module versions under "Packages" #213770
- Process go.mod like package.json #212708 (closed)
- List dependencies under "Packages"?
- Proxy 3rd party packages (dependency proxy) #213907
- Checksum database (sum.golang.org) #213907
- Package feed/index (index.golang.org) #213907
Permissions and Security
- Developers and above will be able to pull items from the GitLab Go Proxy
Documentation
- Add a new section to the package registry user guides for the Go Repository at https://docs.gitlab.com/ee/user/project/packages/go_repository.html
- Packages Admin
What does success look like, and how can we measure that?
The goal of the Package Group is to ensure that in 3 years, 90% of our customers are using GitLab as their sole package registry. Success for this issue will be that we begin to empower Go developers to utilize GitLab for pulling Go packages.