Add vanity URL support to GitLab's built-in Go proxy
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.
The Go tool chain's dependency resolution mechanisms allow a package's repository to live at a different URL than the package's name indicates. For example, the repository of rsc.io/quote is https://github.com/rsc/quote. go get rsc.io/quote executes GET https://rsc.io/quote?go-get=1, which responds with a meta tag that points to https://github.com/rsc/quote.
Problem to solve
GitLab's Go module support (!27746 (merged), #27376 (closed)) recognizes that gitlab.com/my/project has Go modules if and only if the module name is or starts with gitlab.com/my/project (e.g. gitlab.com/my/project/xyz) and if the repository contains a go.mod file at the appropriate location (e.g. /go.mod, /xyz/go.mod, etc) and if that file contains a correct moduledirective (e.g.module gitlab.com/my/project`, etc).
This should be expanded to support vanity URLs, such that GitLab will recognize projects that define modules using vanity URLs. This should involve a check to verify that the vanity URL actually points to the project in question, in a similar manner to validating a custom domain for Pages. The simplest way to implement this would be to require a user action, which would then run GET my.com/project?go-get=1 and verify that the response includes a go-import meta tag that points to the GitLab repository.
Intended users
Further details
TODO
Proposal
Essentially, I propose some mechanism that allows the user to assert that GitLab should recognize modules in a project when those modules use a vanity URL instead of gitlab.com/my/project. And that mechanism should verify that GET https://example.com/my/project?go-get=1 includes <meta name="go-import" content="example.com/my/project git https://gitlab.com/my/project.git">. And a second action to revert.
The first step could be an API endpoint that stores a list of valid vanity URLs in the database, which would be used by the Go module finder (currently Packages::GoModule and Packages::GoModuleVersion) to allow those URLs.
The check should probably be periodically repeated. I think Pages does this for custom domains?
Permissions and Security
Maybe reuse the package create/delete permissions?
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?
Modules that use vanity URLs:
- Can be fetched from the Go module proxy of the project they are defined by, pending !27746 (merged)
- Are included in responses from the Package API and in the Package UI, pending #213770 (closed)
What is the type of buyer?
This is mostly a branding thing. I'm not sure if there's a particular level of buyer who would care most about this.
Is this a cross-stage feature?
Not sure.