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).