Don't cache if GOMODCACHE is missing/empty #720
Description
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 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?
Absolutely. I would just like a sanity check on my thoughts above before I change any code. Thank you!