go1.23 support is currently available at https://github.com/ldez/golangci-lint/tree/feat/go1.23, but due to limitations of goinstall, it must be manually git cloned and then go install. Adding the none installation option allows users to perform this step themselves and still benefit from the cache mechanism provided by this action.

I wonder if the fact of looking for the binary inside the PATH should be a hard restriction or if the action should allow to define a path to a binary.
Cleary, using the PATH is easier.
I'm still thinking 🤔

@jlevesy what is exactly the problem with the current installation of golangci-lint binary?
Are you using a custom golangci-lint version?
Is there a problem with the binary download?
Is it related to custom linters?

Are you using a custom golangci-lint version?

No.

Is there a problem with the binary download?

Yes. I'm looking into the possibility of using something else (devbox) to install golangci-lint in the workflow.

Is it related to custom linters?

No.

What is exactly the problem with the current installation of golangci-lint binary?

With the following devbox.json file at the root of my repository

{
    "packages": [
        "go@1.22",
        "golangci-lint@1.59"
    ]
}

Then I can have the following CI workflow defined with the described behavior:

name: CI
on: [pull_request]
jobs:
  ci:
    name: CI
    runs-on: ubuntu-22.04
    steps:
      - name: Checks out the code
        uses: actions/checkout@v3
      - name: Install devbox
        uses: jetify-com/devbox-install-action@v0.10.0 # <- installs go and golangci-lint, makes them available into the path
      - name: Run Linter
        uses: golangci/golangci-lint-action@v6 # <- runs golangci-lint, using the version available from the path.
        with:
           install-mode: none

Maybe we can use install-mode: path/current? Find the golangci-lint in the current path, and throw error if we can't find it.

Thanks a lot!