After second thought, I think the better choice is to only disable cache for golang test by running go clean -testcache before each test suite. There is no reason not to reuse the setup-go cache, as long as there is no code change.

After second thought, I think the better choice is to only disable cache for golang test by running go clean -testcache before each test suite. There is no reason not to reuse the setup-go cache, as long as there is no code change.

This also crossed my mind. I'm going to hit pause on any more work here just to see if @serathius or anyone else has a preference on which cache prevention option to use (for the record I'm happy with either approach as both address the issue and I think overall performance of one versus the other will be minimal).

For reference, doing a completely fresh setup-go with zero cache only takes our machines 8 seconds, refer: https://github.com/etcd-io/etcd/actions/runs/5138723612/jobs/9248351335?pr=15989, versus 1 second with cache.

No cache looks good to me (8s is ok). or we can force to run test case with make test GO_TEST_FLAGS="-count=1" with build cache.

Caching go mod 👍
Caching go build 👍
Caching go test 👎

Thanks for the feedback everyone - I've switched to the more targeted approach of just doing the go clean -testcache before each suite runs.

I've run multiple workflow runs to verify this is working as expected and we no longer see any cache for the common e2e tests as we were previously. Refer latest run https://github.com/etcd-io/etcd/actions/runs/5143019041/jobs/9257510705?pr=15989.

Please consider to disable golang test cache for all workflows as a followup PR

Defined follow-up task here as a good first issue #15995