Most dependency management systems are artifact-based, whereas Go's dependency management is source-based. That is, for most languages, releasing a new (version of a) package involves uploading some form of artifact to a package registry/repository. Some languages upload source and some upload binaries. However, Go has no notion of a package registry or repository. Instead of a package registry, Go fetches a package directly from its version control system.
Go packages necessarily cannot have name collisions because the name of a Go package must include the URL from which it can be fetched (e.g.
golang.org/x/text). Only the standard library is allowed to omit a domain (e.g.
Go 1.13 introduced the notion of a Go proxy. Prior to this, or with the proxy disabled,
go fetches packages directly from their VCS. The Go proxy protocol is a simple HTTP protocol that facilitates caching, avoids interfacing directly with a VCS, and allows
go to fetch only what is needed instead of cloning the entire source repository.
What does this MR do?
This MR implements a Go proxy MVC, which is the equivalent of a Go package manager. The MVC will not act as a dependency proxy and will only serve modules that correspond to projects on the instance that have enabled (Go) package management. The MVC will not serve legacy Go packages, i.e. those which do not have a
This MR will implement an API endpoint conformant to the Go module proxy protocol. This endpoint will initially be available at
Closes #27376 (closed)
- Handling pseudo-versions and tags that might mask those
Per discussion and
go's approach, tags that match the pseudo-version pattern will be ignored
- Omitting module versions with an invalid
Per discussion, err on the side of omission, because relaxing restrictions is backwards compatible but the inverse is not
- What response should be returned when the request does not match a visible project?
401 when unauthenticated and 404 when authenticated, to support tooling that only prompts for credentials on 401.
Does this MR meet the acceptance criteria?
Documentation (if required)
Code review guidelines
Merge request performance guidelines
Separation of EE specific content
Availability and Testing
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
Tested in all supported browsers
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
Label as security and @ mention
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
Security reports checked/validated by a reviewer from the AppSec team
Beyond the MVC
Buyer: Engineering (full support for Go modules stored on GitLab)
Proxy modules from projects requiring authenticationDone
- Group-level configuration and API endpoint #213900
- Instance-level configuration and API endpoint #213902
- Proxy legacy packages (those that do not define any modules, i.e. having no
- Module discoverability under the
go.modwith hyperlinks to dependencies #212708 (closed)