go build is re-building everyting with enabled cache

[ernado]

Description:
Having cache enabled, I see that output of go build -v contains every package, including ones from standard library, even with enabled cache (I've restarted particular successful job to ensure that cache is available).

Run actions/setup-go@v4
Setup go version spec 1.20.x
Found in cache @ /opt/hostedtoolcache/go/1.20.2/x64
Added go to the path
Successfully set up Go version 1.20.x
/opt/hostedtoolcache/go/1.20.2/x64/bin/go env GOMODCACHE
/opt/hostedtoolcache/go/1.20.2/x64/bin/go env GOCACHE
/home/runner/go/pkg/mod
/home/runner/.cache/go-build
Received 260046848 of 269948098 (96.3%), 247.5 MBs/sec
Received 269948098 of 269948098 (100.0%), 202.1 MBs/sec
Cache Size: ~257 MB (269948098 B)
/usr/bin/tar -z -xf /home/runner/work/_temp/cd6694c0-326a-4[15](https://github.com/go-faster/bot/actions/runs/4509244129/jobs/7960977725#step:3:16)b-90e6-f7bc65bb21bd/cache.tgz -P -C /home/runner/work/bot/bot
Cache restored successfully
Cache restored from key: setup-go-Linux-go-1.20.2-52cf0[19](https://github.com/go-faster/bot/actions/runs/4509244129/jobs/7960977725#step:3:20)537b407a2[20](https://github.com/go-faster/bot/actions/runs/4509244129/jobs/7960977725#step:3:21)c7f76adf3e438bba6f6bf5696aac456c6a7e2972c3896c
go version go1.20.2 linux/amd6

Run go build -v ./cmd/bot
  
internal/unsafeheader
internal/goarch
internal/cpu
internal/abi
internal/coverage/rtcov
internal/bytealg
internal/goexperiment
internal/goos
runtime/internal/math
runtime/internal/atomic
runtime/internal/sys
runtime/internal/syscall
internal/race
sync/atomic
internal/itoa
math/bits
math
unicode/utf8
unicode
container/list
crypto/internal/alias
crypto/subtle
crypto/internal/boring/sig
unicode/utf16
vendor/golang.org/x/crypto/cryptobyte/asn1
internal/nettrace
vendor/golang.org/x/crypto/internal/alias
github.com/klauspost/compress
github.com/klauspost/compress/internal/cpuinfo
github.com/pierrec/lz4/v4/internal/lz4errors
encoding
runtime

Package cache is working as expected, no re-downloads are in logs.

Also I've inspected logs to be 100% sure that go-build cache is attempted to be restored.

../../../.cache/go-build/62/
../../../.cache/go-build/62/620facbf68a104c8be6472789c9748e570dc275e595b2befa57c2b14f2acd561-d
../../../.cache/go-build/d2/
../../../.cache/go-build/d2/d238fa1224f9e27d360a8f26865f7aebf00b2d881fd861b7cd3a20664d08d7f8-d
../../../.cache/go-build/d2/d2a278b96706755bd22345217d5c70c684fa006d9f900ec8a2c4a24efe0e978b-d
../../../.cache/go-build/c2/
../../../.cache/go-build/c2/c2307359f6363bb19583c86942f24fba6447411dc36a03b5bd709716dbe13160-d
../../../.cache/go-build/c2/c2b841163dde7d7e5e9c555c2482c8e0788584bdc798b830da335cdef83a05fc-a
../../../.cache/go-build/c2/c2de9efff83f75bfaeb6e1abac852018f0e73ea688cace37c70830832aa2d925-a
Cache Size: ~257 MB (269948098 B)
/usr/bin/tar -z -xf /home/runner/work/_temp/85321343-e058-46c1-b5e3-d9613fddb74f/cache.tgz -P -C /home/runner/work/bot/bot
Cache restored successfully
Cache restored from key: setup-go-Linux-go-1.20.2-52cf019537b407a220c7f76adf3e438bba6f6bf5696aac456c6a7e2972c3896c
##[add-matcher]/home/runner/work/_actions/actions/setup-go/v4/matchers.json

Is there a possibility that build cache is extracted under wrong path?

Action version:

actions/setup-go@v4

Platform:

• Ubuntu

Runner type:

• Hosted

Tools version:
go1.20.x

Repro steps:

• First run, without cache: https://github.com/go-faster/bot/actions/runs/4509244129/jobs/7938771757
• Second run, with cache and debug logs: https://github.com/go-faster/bot/actions/runs/4509244129/jobs/7960912332
• Third run, with cache, without debug: https://github.com/go-faster/bot/actions/runs/4509244129/jobs/7960977725

I've also set up cache manually for another repo:

- name: Get Go environment
  id: go-env
  run: |
    echo "cache=$(go env GOCACHE)" >> $GITHUB_ENV
    echo "modcache=$(go env GOMODCACHE)" >> $GITHUB_ENV
- name: Set up cache
  uses: actions/cache@v3
  with:
    path: |
      ${{ env.cache }}
      ${{ env.modcache }}
      ${{ env.lintcache }}
    key: lint-${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}
    restore-keys: |
      lint-${{ runner.os }}-go-

This worked well, go build was ~1s: https://github.com/gotd/testbot/actions/runs/4520023665/jobs/7960859969

Expected behavior:
Go compiler can use build cache to speed up compilation.

Actual behavior:
Go compiler is building every package, build cache is not used.

[dsame]

Hello @ernado , thanks for your input, we are starting to investigate the issue

[dsame]

Hello @ernado

I tried to reproduce the problem in the simplified environment and the build shows it works as expected

Moreover the logs of you build shows the both caches (packages and intermediate build results) are restored as well: packages and build cache

The reason the packages are rebuilt can be caused some reasons not related to the action: changing compiler options, target platform, switching branches.

I am not sure how does docker steps from your workflow impact the build but advise to add the command go env GOCACHE right before go build -v to make sure it points to .cache/go-build and the cache directory is mounted to the correct destination in case the build runs within docker container.

Does this answer helps?

[ernado]

Thank you for response!

I'll try to quickly create a simplified environment and check myself.
If it will be ok, I'll close this issue.

[ernado]

I can confirm that in simplified environment it works:

• https://github.com/ernado/setup-go-cache/actions/runs/4535650492/jobs/7991360423 (auto)
• https://github.com/ernado/setup-go-cache/actions/runs/4535650494/jobs/7991360426 (manual)

[ernado]

@dsame this was not a bug, but a race between multiple workflows.

I have a job check-mod that only does go mod download && go mod tidy.
This job created a cache key without build cache, which was reused by other workflows.

This resulted in the situation I've described in issue.

To fix this, I propose to add configurable cache prefixes, like that: #358. I've also describe a workaround.

[dsame]

Hello @ernado, i am going to close the issue according to the comment you've made but please feel free to reopen it or create new one if the problem still exists

[ernado]

Hey @dsame, I’m ok with closing this issue, thank you!