- Enable the Go proxy
- Add GitLab as a Go proxy
- Fetch modules from private projects
- Working with Go
With the Go proxy for GitLab, every project in GitLab can be fetched with the Go proxy protocol.
The Go proxy for GitLab is under development, and isn’t ready for production use due to potential performance issues with large repositories.
It’s deployed behind a feature flag that is disabled by default.
GitLab administrators with access to the GitLab Rails console can enable it for your instance.
To enable it:
Feature.enable(:go_proxy) # or
To disable it:
To enable or disable it for specific projects:
Feature.enable(:go_proxy, Project.find(1)) Feature.disable(:go_proxy, Project.find(2))
To use GitLab as a Go proxy, you must be using Go 1.13 or later.
The available proxy endpoint is for fetching modules by project:
To fetch Go modules from GitLab, add the project-specific endpoint to
Go queries the endpoint and falls back to the default behavior:
go env -w GOPROXY='https://gitlab.example.com/api/v4/projects/1234/packages/go,https://proxy.golang.org,direct'
With this configuration, Go fetches dependencies in this order:
- Go attempts to fetch from the project-specific Go proxy.
- Go attempts to fetch from proxy.golang.org.
- Go fetches directly with version control system operations (like
svn checkout, and so on).
GOPROXY isn’t specified, Go follows steps 2 and 3, which corresponds to
contains only the project-specific endpoint, Go queries only that endpoint.
For details about how to set Go environment variables, see Set environment variables.
For details about configuring
Dependency Management in Go > Proxies.
go doesn’t support transmitting credentials over insecure connections. The
following steps work only if GitLab is configured for HTTPS:
- Configure Go to include HTTP basic authentication credentials when fetching from the Go proxy for GitLab.
- Configure Go to skip downloading of checksums for private GitLab projects from the public checksum database.
Create a personal access token with
the scope set to
and add the following text. Replace the variables in
< > with your values.
machine <url> login <username> password <token>
<url>: The GitLab URL, for example
<username>: Your username.
<token>: Your personal access token.
When downloading dependencies with Go 1.13 and later, fetched sources are
validated against the checksum database
If the checksum of the fetched sources doesn’t match the checksum from the database, Go doesn’t build the dependency.
Private modules fail to build because
sum.golang.org can’t fetch the source
of private modules, and so it cannot provide a checksum.
To resolve this issue, set
GONOSUMDB to a comma-separated list of private
projects. For details about setting Go environment variables, see
Set environment variables. For more details about
disabling this feature of Go, see
Dependency Management in Go > Checksums.
For example, to disable checksum queries for
go env -w GONOSUMDB='gitlab.com/my/project,<previous value>'
If you’re unfamiliar with managing dependencies in Go, or Go in general, review the following documentation:
Go uses environment variables to control various features. You can manage these
variables in all the usual ways. However, Go 1.14 reads and writes Go
environment variables to and from a special Go environment file,
GOENVis set to a file, Go reads and writes to and from that file instead.
GOENVis not set but
GOPATHis set, Go reads and writes
Go environment variables can be read with
go env <var> and, in Go 1.14 and
later, can be written with
go env -w <var>=<value>. For example,
go env GOPATH or
go env -w GOPATH=/go.
Go modules and module versions are defined by source repositories, such as Git,
SVN, and Mercurial. A module is a repository that contains
go.mod and Go
files. Module versions are defined by version control system (VCS) tags.
To publish a module, push
go.mod and source files to a VCS repository. To
publish a module version, push a VCS tag.
See Dependency Management in Go > Versioning for more details about what constitutes a valid module or module version.