Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: Allow go mod cache location to be overridden, e.g. GOMODCACHE (for CI purposes) #31283

Closed
dionysius opened this issue Apr 5, 2019 · 9 comments
Labels
FrozenDueToAge modules WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@dionysius
Copy link

dionysius commented Apr 5, 2019

What version of Go are you using (go version)?

$ go version
go version go1.11.5 linux/amd64

Does this issue reproduce with the latest release?

No documentation about wished behaviour found

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/dionysius/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/dionysius/Projects/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go-1.11"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.11/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build210250960=/tmp/go-build -gno-record-gcc-switches"

What did you expect?

There seem not to exist something what I'd like to do (yet). The issue is, freshly loading all dependent modules can take some time and network I/O. If the CI jobs are split into each type, all of them load concurrently the same cache for their own lifetime - think of: unit-test, unit with race, linting, building, all separated. And if each job is spawned from a clean golang image, like with docker for example, the cache starts empty.

In Gitlab, the cache option can be used, but must be within the projects source dir. I already used the cache option once for GOCACHE and GODEPCACHE (i believe the env name was that) to overwrite their location to my liking. But I seem unable to set the cache path for modules. How about a GOMODCACHE env, which would be used if non-empty?

I know that the mod cache dir is in $GOPATH/pkg/mod, but changing the full GOPATH to somewhere within the source folder seems off to me.

@bradfitz
Copy link
Contributor

bradfitz commented Apr 5, 2019

/cc @bcmills

@bcmills
Copy link
Contributor

bcmills commented Apr 5, 2019

Why is it important that the cache location to be independent of GOPATH? (That is, why can't your CI system save $GOPATH/pkg/mod where it is?)

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Apr 5, 2019
@dpinela
Copy link
Contributor

dpinela commented Apr 5, 2019

You could also change GOPATH itself, and set GO111MODULE=on if needed - that's what I did when I needed to change the module cache location for GitLab CI to be able to store it. I don't remember the exact issue I had but I think it was similar to yours.

@dmitshur dmitshur changed the title Allow go mod cache location to be overridden, e.g. GOMODCACHE (for CI purposes) cmd/go: Allow go mod cache location to be overridden, e.g. GOMODCACHE (for CI purposes) Apr 6, 2019
@dionysius
Copy link
Author

dionysius commented Apr 8, 2019

@bcmills: Why is it important that the cache location to be independent of GOPATH? (That is, why can't your CI system save $GOPATH/pkg/mod where it is?)

It was basically more like a question. I am coming from the old godep since a while, where there was a GODEPCACHE env, but there is honestly no technical limitation for this as of now, as lined out by @dpinela . I could just put the whole GOPATH into that cache folder. And because of the flexibility I have in gitlab-ci, I can also decide myself if I want specific GOPATH/* folders to be included in the cache or not.

I'm currently overthinking my whole suggestion and writing down my thoughts:

  • Thanks to go modules, the GOPATH itself as a whole is kind of a cache for different things now (Not exactly, but you probably can see what I mean) and lost a bit of "importance" for projects.
  • Depending on the use-case, we could possibly see GOBIN as deprecated, but I can definitely see some cases where you want GOBIN somewhere else than GOPATH/bin (and also for compatibility for sure)
  • If, in the future, there's a new feature requiring a new folder within GOPATH, you'd have to think again about introducing a new env variable for that. If we/you just don't add them, it will be the same idiomatic way golang approaches, keeping it simple and clear (where GOPATH is the entrypoint for everything). And once there is a real requirement for it, we can have a look into that specificly

I could see this closed, I was thinking too much "the old way" and there's no technical requirement as of now

@mvdan
Copy link
Member

mvdan commented Sep 9, 2019

Here's a reason I think this could be helpful.

With go env -w, I can globally set env variables on CI, such as GOCACHE, CGO_ENABLED, or GOBIN.

Unfortunately, many environments explicitly set GOPATH - including the official Docker images, for example. So I can't just do something like go env -w GOPATH=/cache/gopath.

The answer here could be "simply override the GOPATH env var", but that's difficult to do in some environments. For example, Drone CI has no way to set global environment variables, so I have to repeat it at every build step. This is the kind of thing that I hoped go env -w would simplify.

This would indeed be fixed by a GOMODCACHE, since then I'd do something like go env -w GOMODCACHE=/cache/modcache GOCACHE=/cache/buildcache.

@lfaoro
Copy link

lfaoro commented Sep 27, 2019

@dionysius you can copy the cache inside the project folder and then cache it with gilabci -- before building you move the cache back in $GOPATH/pkg/mod

e.g.
cp -r $GOPATH/pkg/mod ./modcache
ci yaml: cache: paths: - modcache/
before go build:
ci yaml: before_script:
cp -r ./modcache $GOPATH/pkg/mod

or use vendor and set in ci:

variables:
 GOFLAGS: -mod=vendor

@TudorHulban
Copy link

What if I would like to set the cache on a RAMDISK (and not wear the SSD)?

@mvdan
Copy link
Member

mvdan commented May 6, 2020

@TudorHulban GOMODCACHE was implemented in #34527, and it will ship with Go 1.15.

@dionysius
Copy link
Author

Wooooow! Good to hear!

@golang golang locked and limited conversation to collaborators May 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

8 participants