Bump golangci/golangci-lint-action from 4 to 6

[albertony]

Version 5 removes Go cache management, and therefore also options skip-pkg-cache and skip-build-cache, because the cache related to Go itself is already handled by actions/setup-go. Now it only caches golangci-lint analysis. Our solution in #7776 therefore needed to be changed.

What is the purpose of this change?

Was the change discussed in an issue or in the forum before?

Checklist

• I have read the contribution guidelines.
• I have added tests for all changes in this PR if appropriate.
• I have added documentation for the changes if appropriate.
• All commit messages are in house style.
• I'm done, this Pull Request is ready for review :-)

[ncw]

Looks good and it is all working. Please merge, thank you :-)

[albertony]

I think this still needs some tweaking. I need to step back a little, into the experimenting done in the recent PR. The behavior depends on existing cache, if exact match on cache key (restore but not save), partial match based on restore key (restore and save), or no match (no restore but save). Current version does not handle all these cases as it should, I think.

One issue is that the setup-go built-in caching in the lint job gets the same cache key as the setup-go step of the build job, and then it fails to be saved, and then it will not include the build/module cache from all the GOOS-specific golangci-lint runs.

Failed to save: Unable to reserve cache with key setup-go-Linux-ubuntu22-go-1.22.2-1fb3fc7c6c788962f23b18402cc60ecc7b5e7aa2b6732a1f84a1236726dbd912, another job may be creating this cache. More details: Cache already exists. Scope: refs/pull/7803/merge, Key: setup-go-Linux-ubuntu22-go-1.22.2-1fb3fc7c6c788962f23b18402cc60ecc7b5e7aa2b6732a1f84a1236726dbd912, Version: 1cb9802e5b5c597f946446bf4b3344ff6eb214d674e7138050afa0c8b9619604

What I think I must do in this lint job is to disable all built-in caching, in all of setup-go and golangci-lint-action, and add a custom cache step with actions/cache, which caches everything (build, modules, analysis), which would give the result that I want, same as I ended with in the previous PR.

[albertony]

I have a version now, with a separate cache step, which gives the results corresponding to the previous PR. I think is good now, but will do a few more test runs.

The main decision when using the cache action is the cache key.

• Setup go uses cache key:

  setup-go-${platform}-${linuxVersion}go-${versionSpec}-${fileHash}
  

  setup-go-Linux-ubuntu22-go-1.21.9-1fb3fc7c6c788962f23b18402cc60ecc7b5e7aa2b6732a1f84a1236726dbd912

  It does not use separate restore keys, i.e. requires exact match on the primary cache key for it to re-use a cache.

  The fileHash is the hash of go.mod.

• golangci-lint-action uses primary cache key:

  golangci-lint.cache-{interval_number}-{go.mod_hash}
  

  golangci-lint.cache-2834-820432f836f6c171106fffde2baea2a6de7ef88e

  and a separate restore key which is without the hash, i.e. even if go.mod changes it will still be able to re-use an existing cache, and will then save back a new cache entry with the primary key based on the changed go.mod hash.

  The interval number: "ensures that we periodically invalidate our cache (every 7 days). go.mod hash ensures that we invalidate the cache early - as soon as dependencies have changed." (https://github.com/golangci/golangci-lint-action/?tab=readme-ov-file#caching-internals).

• My current suggestion for the lint job is to use something of a hybrid between the two above, with primary cache key:

  golangci-lint-${{ steps.get-runner-details.outputs.runner-os-version }}-go${{ steps.setup-go.go-version }}-${{ steps.get-runner-details.outputs.year-week }}-${{ hashFiles('go.sum') }}
  

  golangci-lint-ubuntu22-go1.22.2-202417-1fb3fc7c6c788962f23b18402cc60ecc7b5e7aa2b6732a1f84a1236726dbd912

  With a restore key without the hash.

  I'm pretty sure this should work well, and it will be on the safe side - not using a cache if anything in the environment has changed, and re-creating the cache weekly even if nothing has changed (similar to what golangci-lint-action does). The only thing I'm not sure about is the practical difference between using the hash of go.sum (like setup-go does) and go.mod (like golangci-lint-action does) - if any at all?

[albertony]

@ncw Does your approval still apply? 😄 Should I merge it now?

PS: Sorry for doing all the extra iterations and pushes since your last comment/approval, once again, leading to noise in your github notifications. Oh, and with this I guess I'm just adding even more... 😟

[albertony]

Bumped golangci-lint-action further past version 5 directly to 6.

[ncw]

Yes, let's give this a go 😃