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: "go help cache" does not specify if concurrent invocations of go are safe wrt the cache #26677

Open
mark-rushakoff opened this issue Jul 29, 2018 · 3 comments
Labels
Documentation NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@mark-rushakoff
Copy link
Contributor

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
Copy link
Member

@bcmills
@gopherbot label NeedsInvestigation

@gopherbot gopherbot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 30, 2018
@andybons andybons added this to the Go1.11 milestone Jul 30, 2018
@bcmills
Copy link
Contributor

bcmills commented Jul 30, 2018

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

@bcmills bcmills self-assigned this Aug 1, 2018
@rsc rsc modified the milestones: Go1.11, Go1.12 Aug 17, 2018
@rsc rsc added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Aug 17, 2018
@apparentlymart
Copy link

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.

@bcmills bcmills modified the milestones: Go1.12, Go1.13 Jan 18, 2019
@andybons andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@rsc rsc unassigned bcmills Jun 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants