go / test-cache

updated July 19, 2026

go test caches passing test results and compiled packages, so an unchanged package's tests can return instantly. To make that cache survive across CI runs, persist the caches and make each test binary depend only on its source.

The caches

Go keeps two on-disk caches:

• GOCACHE: compiled packages and test results.
• GOMODCACHE: downloaded module source.

On a CI VM I put both on the local disk and reuse them across runs, so a warm box recompiles and retests only what changed:

export GOCACHE=/var/cache/ci/go-cache
export GOMODCACHE=/var/cache/ci/go-mod

Keep results caching

The test result cache keys on the inputs to each test binary. Two defaults change those inputs across CI runs, so nothing hits:

• go test stamps the binary with VCS info, so every new commit produces a different binary.
• The absolute source path is compiled in, so cloning a job into a different directory per box changes the path.

Two flags make a binary depend only on its source:

go test -buildvcs=false -trimpath ./...

-buildvcs=false drops the commit stamp. -trimpath removes absolute paths. With both, identical source produces an identical binary, so cached results are reused across commits and across boxes that share a GOCACHE.

Result

The first run at a given source state populates the cache. The next run on the same source reports (cached) for unchanged packages and finishes in seconds instead of tens of seconds. This is the CI cache behavior behind cmd / cibot.

← All articles