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

[tinyzimmer]

Welcome

• Yes, I understand that the GitHub action repository is not the repository of golangci-lint itself.
• Yes, I've searched similar issues on GitHub and didn't find any.

Your feature request related to a problem? Please describe.

The actions/setup-go action which is a requirement of this action already, has automatic caching now. When using that feature with skip-pkg-cache: false it causes many annotations to appear like the following screenshot.

Describe the solution you'd like.

Would it be possible to just have this action store it's caches in the same directories the actions/setup-go action uses? Then things should just work out of the box I assume.

Describe alternatives you've considered.

Setting skip-pkg-cache: true when using the latest setup-go actions.

Additional context.

Not much. But happy to provide.

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

[bas-ie]

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

[navijation]

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.

[bas-ie]

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.