caches: Do we really need them anymore? The current implementation conflicts with automatic caching in latest `setup-go`.

[tinyzimmer]

caches: Do we really need them anymore? The current implementation conflicts with automatic caching in latest `setup-go`.

[NavneethJayendran]

I believe the cache does not simply contain Go's build artifacts: it also caches the analyzer facts / reporting for each package and reuses cached outputs when the dependency closure for a package doesn't change.

It might warrant creating an option to skip the go build cache specifically though.

[tinyzimmer]

On second thought. The combination of telling setup-go to not cache and then using this action regularly is another solution. I guess I'm wondering if for simpler cases there should be a similar cache: false for this action in case one wants to use the default one from setup-go.

[richchurcher]

We're seeing this as well. Related to #387 and #807 (among probably others).

[richchurcher]

Yes, or even potentially just writing to a path that won't conflict. You could even provide an option to summarise the exit 2 from tar as "some cache paths could not be written due to the file already existing", since not doing it generates screeds of warnings/errors. It's also worth noting that our very rough testing showed that jobs where these errors occurred were also slower than those which completed without error.