I’m wanting to make my CI pipeline for one of my projects be able to do a go get on a private module that is hosted in a repo in the same group, but I can’t seem to get it working.
To further explain what I mean, I have a project called Prism API (gitlab.com/utiliflex/Juice/prism-api/) Now that project depends on a private Go module called Prsm (gitlab.com/utiliflex/Juice/misc/prism). In the go.mod file for Prism API I have the following line
require (
gitlab.com/utiliflex/Juice/misc/prism v0.0.0-20220603153852-7332137e1b80
)
On my local system, I am able to set the GOPRIVATE environment variable, setup my $HOME/.netrc and was able to go get the module (which is how it was added to the go.mod file). The problem comes in when I try to do the same in my CI pipeline. In my .gitlab-ci.yml file I have the following.
before_script:
- export PATH="/usr/local/go/bin:$GOPATH/bin:$PATH"
- export GOPRIVATE="gitlab.com/utiliflex"
- curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.46.2
- |
echo "machine gitlab.com login ${GITLAB_USER} password ${GITLAB_TOKEN}" > ~/.netrc
But when the pipeline runs everything fails and I get the following error:
go: downloading gitlab.com/utiliflex/Juice/misc/prism v0.0.0-20220603153852-7332137e1b80
go: downloading gitlab.com/utiliflex/Juice/misc/prism v0.0.0-20220603153852-7332137e1b80
internal/database/meters.go:7:2: gitlab.com/utiliflex/Juice/misc/prism@v0.0.0-20220603153852-7332137e1b80: invalid version: git ls-remote -q origin in /home/gitlab-runner/go/pkg/mod/cache/vcs/9ef489ce5396bed8f907bd5d29f8365be2cfc6dcd85859e4a72bef2a029cfcaa: exit status 128:
fatal: could not read Username for 'https://gitlab.com': terminal prompts disabled
Confirm the import path was entered correctly.
If this is a private repository, see https://golang.org/doc/faq#git_https for additional information.
*** Error code 1
I’m aware that by default go get uses HTTP(S) to fetch the module which is why the .netrc file worked for auth on my local, but I don’t know why it’s not working in GitLab’s CI. As for the runner that the CI pipeline runs on is one I host using the “shell” executor.