<!--- Please direct any generic questions related to actions to our support community forum at https://github.com/orgs/community/discussions/categories/actions ---> <!--- Before opening up a new feature request, please make sure to check for similar existing issues and pull requests --> **Description:** I think there is an argument that this is really a bug in the caching behavior, but I will defer to your judgement. The [two cache folders](https://github.com/actions/setup-go/blob/main/src/package-managers.ts#L13) that `setup-go` caches are `GOCACHE` and `GOMODCACHE`. `GOCACHE` only contains cache related to builds. If this gets wiped away, no network calls are required and it just requires rebuilding of all the local sources. `GOMODCACHE` contains all the module source code. If this gets wiped away, all modules need to be re-downloaded from the Internet. The problem comes when you use `actions/go-setup`, not understanding how the underlying caching mechanisms work, and you have a quick workflow that doesn't pull any modules. This means the cache that gets committed is basically empty. In the case where I stumbled upon this, it was a workflow that literally just calls `gofmt` and does an automatic commit if there are formatting changes created. That means, unknowingly, we made the cache feature of `actions/go-setup` fairly useless. On that same workflow, I noticed the log: > Warning: Cache folder path is retrieved but doesn't exist on disk: /home/runner/go/pkg/mod Now, a question for those who know more than me: are there any legitimate scenarios where `GOMODCACHE` would be empty and someone would still want to create the cache? The only scenario that comes to my mind would involve a repo where modules get checked in under `vendor/`. In that case, is there any chance of checking for a `./vendor` directory (I'm not sure if you have access to the checked out repos or not -- this may not be possible) or checking `go env GOFLAGS` to see if `-mod=vendor` is specified and avoiding caching if it is? The request for consideration is to make the default behavior to only cache when `GOMODCACHE` actually has data and, if needed, provide a flag for caching regardless. This could be a cache priority flag where you can opt to prioritize network vs compute or passing a `with:` parameter of `vendored: true` to override the default behavior. **Justification:** As-is, CI Checks can easily and unintentionally invalidate the usefulness of the `setup-go` cache feature. **Are you willing to submit a PR?** <!--- We accept contributions! --> Absolutely. I would just like a sanity check on my thoughts above before I change any code. Thank you!