Disable the golangci-lint-action's own Go mod & Go build caches #181
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of your changes
We already manage Go mod & build caches for the CI jobs of the official provider repositories to speed up the build times. The golangci-lint action that we use to run the linter can itself maintain the Go build and mod caches, however, with a different cache key than we use, with the syntax explained here.
This PR proposes to disable that action's own Go build and mod caches and use the caches we explicitly maintain, the caches with the keys
Linux-{build, pkg}-lint-
. This should also prevent the occasional tar errors we observe for these cache files.An alternative would just be not populating the build and mod caches explicitly from the
Linux-{build, pkg}-lint-
keys and letting the action manage its own cache. I did not choose this way because it's less efficient than building a single cache with (almost) the same contents (please see the note below).Note: The action caches the whole
pkg
folder instead of thepkg/mod
folder as the caches we explicitly maintain do. The action's cache also has an expiration date, i.e., even if the contents of thego.mod
file does not change, the cache will expire after a certain period of time (one week). From a practical point of view, the explicitly maintained cache should also be fine though.I have:
make reviewable test
to ensure this PR is ready for review.How has this code been tested
Manually tested in the main branch of a fork repo of
upbound/provider-aws
andupbound/provider-azuread
.