← All guides

Go module caching in GitHub Actions: setup-go already does it

Go is the one ecosystem where dependency caching in GitHub Actions is (nearly) free: since v4, actions/setup-go caches your module downloads and build cache by default, keyed on go.sum. If your workflow uses a current setup-go, you may already be done. The catches live in the details.

The baseline

- uses: actions/setup-go@v5
  with:
    go-version: '1.22'

That's it — module cache (~/go/pkg/mod) and build cache (~/.cache/go-build) both restored, no cache: option needed. If you're still on setup-go@v3 or older, the upgrade is the fix: v3 required wiring actions/cache by hand, and most workflows never did.

When to set cache options anyway

Monorepo with the Go module somewhere under the root? Point the key at the right go.sum:

- uses: actions/setup-go@v5
  with:
    go-version-file: 'service/go.mod'
    cache-dependency-path: 'service/go.sum'

hugo's test workflow sets cache: true explicitly on setup-go — redundant on current versions but harmless, and it reads as intent. Setting cache: false is the choice that costs you; the main reason to do it is a very large build cache that restores slower than it saves (measure before you believe that).

So why do Go repos still show up on scorecards?

Because caching was never their problem. The gaps we actually find in Go repos are the universal ones: no concurrency group, no job timeout, and the occasional always-red scheduled workflow. A fast-compiling language hides config debt well. See how popular Go repos run CI →

These hide across however many workflow files you have, which is exactly why nobody sits down and fixes them. Point GitSpider at your repo and it flags which patterns apply, with the fix for each.

Scan your repo free