I sometimes see people who use private Gitlab subgroups to name their Go
modules (mostly libraries) with a suffix
Let’s see an example. If we have a Go module project at the following imaginary location:
Now when running
go get gitlab.com/myuser/foogroup/barlib from another Go project,
even though the SSH keys are set correctly, we may get an error:
The project you were looking for could not be found or you don't have permissions to view it.
We start googling and reading stackoverflow and it seems that a possible solution is to rename
the module to
gitlab.com/myuser/foogroup/barlib.git … and the issue looks fixed.
Also at this point people start to doubt the goodness of the Go tools
go mod and
go get especially) and mark this as a stupid annoying (Go) bug.
The solution is simple and the reason for the issue too and it’s not a bug.
The reason behind that permissions error
Why this happens is that
go get tries to discover the modules at a given path
in order to find the requested Go module repository. Only after the repository is found,
the tools will do
git clone or
git checkout and the SSH keys will be used for authentication.
The issue comes down to the fact that private Gitlab subgroups cannot be listed/viewed
without a Gitlab Access Token.
The fix is Gitlab Access Token
Gitlab->Preferences->Access Tokens and create one. Then create (or edit) a
file in your home folder:
~/.netrc The contents of the file are below:
And we may not need to name our Go modules with a
.git suffix anymore.