I then ran the following commands as root to prime the build cache. (I intentionally set the mtimes and trim.txt file to the past in order to reproduce the bug.)
go clean -cache
go build std
chmod -R a+rwX "${GOCACHE}"
find "${GOCACHE}" -type f -exec touch '{}' -d '2024-07-01 00:00:00' \;
printf '1719792000' > "${GOCACHE}/trim.txt"
Finally I ran go test as a non-root user. (I passed -p=1 to force it to run one package at a time in order to make the bug happen deterministically.)
go test -v -count=1 -p=1 ./...
What did you see happen?
As described in #69565, since the build cache was crafted to look old, go run decided to trim it. This somehow causes go test to break.
=== RUN TestFoo
foo_test.go:16: + /usr/local/go/bin/go run testdata/main.go
--- PASS: TestFoo (0.15s)
PASS
ok gotestbug/pkg1 0.148s
# gotestbug/pkg2 [gotestbug/pkg2.test]
pkg2/bar_test.go:4:2: could not import testing (open /tmp/.gocache/26/26737db8c74b26401dc8828801cc3793a888d7c29c40b7500b7e9e5f96deec19-d: no such file or directory)
FAIL gotestbug/pkg2 [build failed]
FAIL
It should be noted that this issue does not happen if I run go test as root.
What did you expect to see?
The test should pass without any compilation issues.
Go version
go version go1.22.7 linux/amd64
Output of
go env
in your module/workspace:What did you do?
I have the following files:
go.mod
pkg1/foo_test.go
pkg1/testdata/main.go
pkg2/bar_test.go
I then ran the following commands as root to prime the build cache. (I intentionally set the mtimes and trim.txt file to the past in order to reproduce the bug.)
Finally I ran
go test
as a non-root user. (I passed-p=1
to force it to run one package at a time in order to make the bug happen deterministically.)What did you see happen?
As described in #69565, since the build cache was crafted to look old,
go run
decided to trim it. This somehow causesgo test
to break.It should be noted that this issue does not happen if I run
go test
as root.What did you expect to see?
The test should pass without any compilation issues.