cmd/go: should we reuse GOMODCACHE in TestScript? #42017
Comments
mvdan
added
the
NeedsDecision
The It would be possible, perhaps, to use a separate |
|
I don't think there would be much benefit to doing this. Tests that run in There are a number of tests that verify whether something is present in the module cache. If we used the host's module cache, those tests would need to be updated to set Another issue is that we sometimes change the content of modules in the test proxy. We run a test checksum database that keeps up with those changes, but we wouldn't automatically re-fetch a file in the module cache that's out of date. |
|
Fair enough, I agree this is probably not worth it. I only thought of raising an issue because, since it's a new env var separate from |
We started making gotooltest share the host's module download cache with test scripts, since we did it with GOCACHE and it initially made sense. However, the upside is significantly smaller for GOMODCACHE compared to GOCACHE. The build cache can save a significant amount of time, since many tools have to load or build Go packages as part of their tests. In contrast, few tests download modules, and those which do tend to download those modules from a local proxy like goproxytest, which is very fast already. The downsides of sharing the module download cache are a few: * We don't share GOPATH, and since the default GOMODCACHE is GOPATH/pkg/mod, sharing one and not the other is unexpected and inconsistent. * Upstream testscript shares GOCACHE, but does not share GOMODCACHE. See golang/go#42017. * Losing a degree of isolation in the tests is a downside in itself, especially given that sharing GOMODCACHE isn't crucial. This reverts commit c5fd45a. Note that we keep the env.txt test in place, just flipping the expectation that GOMODCACHE does not contain ${WORK}.
We started making gotooltest share the host's module download cache with test scripts, since we did it with GOCACHE and it initially made sense. However, the upside is significantly smaller for GOMODCACHE compared to GOCACHE. The build cache can save a significant amount of time, since many tools have to load or build Go packages as part of their tests. In contrast, few tests download modules, and those which do tend to download those modules from a local proxy like goproxytest, which is very fast already. The downsides of sharing the module download cache are a few: * We don't share GOPATH, and since the default GOMODCACHE is GOPATH/pkg/mod, sharing one and not the other is unexpected and inconsistent. * Upstream testscript shares GOCACHE, but does not share GOMODCACHE. See golang/go#42017. * Losing a degree of isolation in the tests is a downside in itself, especially given that sharing GOMODCACHE isn't crucial. This reverts commit c5fd45a. Note that we keep the env.txt test in place, just flipping the expectation that GOMODCACHE does not contain ${WORK}.
When a txt script file is run as a subtest, we share the host's GOCACHE by default, presumably to allow reusing the build cache and speeding up
go buildcommands inside each test:You can verify this easily:
Should we do the same with the new GOMODCACHE Go environment variable? That would let the tests share the host's module download cache.
The upside is that, for most tests, we would download and copy fewer files, even if it's just the ones in
testdata/mod/.A potential downside is that if a test relies on actual downloads happening, they'd have to unset GOMODCACHE to use an empty module download cache.
Is this worth it? Opening an issue for discussion. /cc @bcmills @jayconrod @matloob
The text was updated successfully, but these errors were encountered: