cmd/go: "go help cache" does not specify if concurrent invocations of go are safe wrt the cache

[mark-rushakoff]

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

go version go1.10.3 darwin/amd64

Does this issue reproduce with the latest release?

Same or nearly same documentation with go version devel +154394f8d3 Sun Jul 29 15:42:29 2018 +0000 darwin/amd64

What did you do?

My team is trying to speed up our CI runs, and I wanted to investigate whether it would be safe for different Jenkins jobs, running go test concurrently, to share the same GOCACHE, to take advantage of test caching. I looked at the output of go help cache and didn't see any mention of expected behavior with concurrent runs of go with respect to the cache.

What did you expect to see?

I expected to see some mention of what is expected to happen when invoking go concurrently. Perhaps "it is safe" to do so, or "if concurrent runs of go attempt to warm the same cache entry, the last one wins", or "concurrent runs of go may fail if the same cache file is modified by a different go process".

What did you see instead?

No mention of expected behavior.

We're intending to assume the best behavior in the meantime, but I was slightly surprised that it wasn't mentioned in the docs.

/cc @rsc

[andybons]

@bcmills
@gopherbot label NeedsInvestigation

[bcmills]

Concurrent uses are explicitly safe. The cache is content-addressed, so the act of populating cache entries should be idempotent.

[apparentlymart]

I think #26794 is somewhat-related. It's not talking about GOCACHE directly, but is another reason why concurrently running go commands may not be safe. Perhaps worth mentioning that in the documentation produced by this issue too.

[gopherbot]

Change https://go.dev/cl/632895 mentions this issue: cmd/go: document the build cache as safe for concurrent use