你使用的Go版本是什么( go version )?

$ go version
go version devel go1.21-518889b35c Thu Feb 16 02:02:00 2023 +0000 linux/amd64

这个问题在最新版本的发布中是否重现？

是的，已通过Go 1.20验证。

你正在使用什么操作系统和处理器架构( go env )?

go env 输出

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/mvdan/.cache/go-build"
GOENV="/home/mvdan/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/mvdan/go/pkg/mod"
GONOPROXY="github.com/cue-unity"
GONOSUMDB="github.com/cue-unity"
GOOS="linux"
GOPATH="/home/mvdan/go"
GOPRIVATE="github.com/cue-unity"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/mvdan/tip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/mvdan/tip/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.21-518889b35c Thu Feb 16 02:02:00 2023 +0000"
GCCGO="gccgo"
GOAMD64="v3"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/mvdan/src/nowt/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3213309622=/tmp/go-build -gno-record-gcc-switches"

你做了什么？

我参与的许多项目都在GitHub Actions上使用go test ./...。其中大多数还使用GitHub的https://github.com/actions/cache来持久化Go的GOCACHE和GOMODCACHE,以便连续的CI运行如果几乎没有代码更改，就可以避免很多工作。
这在很大程度上起作用，但我注意到那些完全没有更改任何代码(例如，只修改README)的提交只会显示一些包为(cached),而其他包总是从头开始运行。例如，参见cue-lang/cue#2253。
经过相当多的调查与GODEBUG=gocachehash=1及其testInputs哈希值，并阅读了src/cmd/go/internal/test/test.go后，我认为原因是修改时间。每当测试打开一个文件时，Go的自动测试缓存会跟踪该文件的路径、文件信息和内容，以了解是否应该在未来重新运行测试。文件信息包括修改时间：

func hashWriteStat(h io.Writer, info fs.FileInfo) {
	fmt.Fprintf(h, "stat %d %x %v %v\n", info.Size(), uint64(info.Mode()), info.ModTime(), info.IsDir())
}

包括修改时间可能对测试缓存本身有用，而且通常在不断发展的机器上连续开发时不是一个问题。然而，CI有点特殊：它很常见地在临时环境中运行并从获取代码开始。特别是，GitHub Actions作为CI的使用方式往往从https://github.com/actions/checkout开始，它使用git clone将仓库下载到类似于/home/runner/work/foobar/foobar的路径。请注意，克隆目录的位置在每次运行之间不会改变；我最初怀疑这是问题所在，但事实并非如此。
问题在于git没有任何方式存储修改时间，而git clone在检出仓库时创建新文件，因此克隆的文件最终具有当前时间作为它们的修改时间。
作为一个复现者和演示示例，我已经编写了https://github.com/mvdan/nowt/tree/master/test-cache-open-modtime。它包含一个打开测试数据的Go测试和一个重现这种情况的脚本：

$ ./repro.bash 
Clone and test twice in a row, using the same directory and -trimpath. The test caching does not work.
-rw-r--r-- 1 mvdan mvdan 8 Feb 16 22:14 test-cache-open-modtime/testdata/foo.txt
ok  	mvdan.cc/nowt/test-cache-open-modtime	0.001s

-rw-r--r-- 1 mvdan mvdan 8 Feb 16 22:14 test-cache-open-modtime/testdata/foo.txt
ok  	mvdan.cc/nowt/test-cache-open-modtime	0.001s

The same again, but this time resetting the testdata file's mtime, since git clone otherwise sets it to the time it ran.
-rw-r--r-- 1 mvdan mvdan 8 Jan  1  2000 test-cache-open-modtime/testdata/foo.txt
ok  	mvdan.cc/nowt/test-cache-open-modtime	0.001s

-rw-r--r-- 1 mvdan mvdan 8 Jan  1  2000 test-cache-open-modtime/testdata/foo.txt
ok  	mvdan.cc/nowt/test-cache-open-modtime	(cached)

你期望看到什么？

我希望修改时间不影响Go的测试缓存命中与未命中决策。特别是因为Go很大程度上允许其开发者不知道修改时间以便增量构建能够良好工作，与其他构建系统如make不同。

你看到了什么？

大多数人在像GitHub Actions这样的流行平台上使用CI会导致不必要的Go测试缓存未命中，这是由于修改时间造成的。
我可以为我的项目通过跟随每个actions/checkout步骤的脚本来修复这个问题，该脚本可以遍历所有克隆的文件并将它们的修改时间重置为静态时间戳。然而，那感觉非常不幸，我想象许多Go用户甚至可能没有意识到他们的CI比一开始就应该慢得多。
我们还可以尝试说服第三方如git clone或actions/checkout在文件上留下可重复的修改时间，但我不认为这是可能的。