Feature request: cache the Go build cache

[CpuID]

Description:

It doesn't look like setup-go caches the Go build cache, only Go modules and other relevant things.

To speed up subsequent builds, should the go-build directories (OS dependent) also be cached automatically in this action?

Some background available in this blog post https://500.keboola.com/in-depth-of-go-build-cache/

Justification:

I had a job that was taking 3+mins for go test to start, turns out it was because of how long it took to "build" the tests before executing them.

By implementing at least the actions/cache@v4 parts suggested in https://500.keboola.com/in-depth-of-go-build-cache/ that 3mins became single digit seconds.

I suspect this may speed up other peoples builds too.

Example logic:

What I ended up doing in Github Actions in addition to setup-go, differed a little from the blog post (cache based on Go version dynamically being fetched, plus OS + CPU architecture)

      - name: Setup go
        uses: actions/setup-go@v5
        with:
          go-version-file: 'go.mod'

      - name: Get go version for build cache key
        run: |
          echo "GO_VERSION=$(go version | cut -d ' ' -f 3 | cut -d 'o' -f 2)" >> $GITHUB_ENV

      - name: Load Go build cache
        id: load-go-cache
        uses: actions/cache@v4
        with:
          path: |
            ~/.cache/go-build
          key:  ${{ runner.os }}-${{ runner.arch }}-go-${{ env.GO_VERSION }}-somethingunique-${{ hashFiles('**/go.sum') }}
          restore-keys: |
            ${{ runner.os }}-${{ runner.arch }}-go-${{ env.GO_VERSION }}-somethingunique-

Are you willing to submit a PR?

Not right now - I implemented this in my own actions logic for now :)

[priyagupta108]

Hi @CpuID 👋,
Thank you for the feature request, we will investigate it and get back to you as soon as we have some feedback.

[gavinsharp]

It looks to me like the caching logic does at least attempt to store both the Go build cache (go env GOCACHE) and module cache (go env GOMODCACHE), see the default packageManagerInfo.cacheFolderCommandList and the associated getCacheDirectoryPath logic.

Perhaps something else was causing this to not work for you @CpuID?

[gavinsharp]

I guess one thing that is different about your alternative example is that it specifies additional restore-keys, which isn't currently supported by this action (see #404). This could impact cache effectiveness (although missed cache hits should be visible in the run logs, I think).

[alicebob]

Perhaps something else was causing this to not work for you @CpuID?

The cache is used for tests, and "works" with the current setup-go action, but the problem is that the cache is written once for a given go.mod, and then never updated. Only when the go.mod changes you get a new cache blob.

So a test can only use the cache if the test and nothing of its dependencies changes, since there can't be any cache updates after the first run.

The best case (for Go), would be if the cache works more as persistent storage: load on the start, then the CI run updates tests and stuff, and then update the cache with the latest version.

This is not how github actions work, so the logic above works by storing a new version every run, and hoping the restore picks a recent version.

Go already checks if the cache is valid. There is no need to do this in the action logic: loading any recent state will help speed things up.

[AlekSi]

I think it is done now: https://github.com/actions/setup-go?tab=readme-ov-file#caching