Sorry for slow reply. We are using Alpine, which I don't think is either of those flavors.
I discovered this by enabling GODEBUG=gocachehash=1, running the tests twice, and then checking the diff between the two test runs. On Tue, Nov 28, 2023 at 11:57 AM 'Bryan C. Mills' via golang-nuts < golang-nuts@googlegroups.com> wrote: > As far as I can tell the code in question is only built on AIX and OpenBSD > — are you using one of those two platforms? > If not, perhaps the caching problem is coming from somewhere else. > > That said, it does appear that calls to `os.Chdir` result in a spurious > dependency on the PWD variable: > > https://cs.opensource.google/go/go/+/master:src/os/file.go;l=340-345;drc=d961b12be9001cf8dbf8f52847607dbf84d94f8d > > On Thursday, November 23, 2023 at 1:50:04 PM UTC-5 Kevin Burke wrote: > >> We have some tests that are pretty slow. I would like to use Go's test >> caching to skip them in our CI environment, if nothing in the code or the >> environment has changed. Our CI environment has a set of _agents_, each of >> which can run multiple jobs simultaneously. As a result, they check out >> code into a different directory each time they run a job. >> >> Go's test caching checks every env var loaded by the test program. If any >> of them change, then Go assumes that the cache is busted and the test must >> be run. >> >> Any program that imports "os" hits this logic in the os package, which >> checks the value of the $PWD environment variable: >> >> // We query the working directory at init, to use it later to search for >> the >> // executable file >> // errWd will be checked later, if we need to use initWd >> var initWd, errWd = Getwd() >> >> So checking code out to different directories means that any program that >> imports "os" cannot have test caching. This seems like a shame because the >> code is all laid out in the same place in the working directory. >> >> Has anyone tried to fix this issue? Do you think this is worth trying to >> patch or modify the test caching behavior in Go itself? I could solve this >> by running a chroot or another layer of Docker, of course, but I'd prefer >> not to do these because of the difficulty of getting data in and out of >> each one, communicating with other Docker containers, etc. >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/74iG66JVA9s/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/9507e736-9d8a-4929-9812-3a89358a1cf3n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/9507e736-9d8a-4929-9812-3a89358a1cf3n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKcy5egYecGK8oSaB1xA439BPQ-BnCKi9vHpafe_qzRtQ_D%2B2w%40mail.gmail.com.
