Specify required version number in config

[jamescmartinez]

Your feature request related to a problem? Please describe.

As a team grows, it's difficult to ensure that we're all running the same version of golangci-lint. This causes inconsistent linting across the team, which was most recently noticed with the upgrade to 1.53.

Describe the solution you'd like.

By specifying a required version number in the config, golangci-lint can enforce that it matches the required version before running.

In the ideal case, the required version number would also be respected by golangci-lint-action, meaning there wouldn't be a need to manually keep the version number in sync in multiple places (e.g., in .github/workflows/ci.yaml and .golangci-lint.yaml.

Describe alternatives you've considered.

We solved this by enforcing a local version in our Taskfile.yaml and ci.yaml:

./Taskfile.yaml:

  lint:
    preconditions:
      - golangci-lint --version | grep -q 1.53
    cmds:
      - golangci-lint run ./...

./.github/workflows/ci.yaml:

      - uses: golangci/golangci-lint-action@v3
        with:
          version: v1.53

Additional context.

Similar to what I'm thinking of, npm has a solution to this with engines and engine-strict.

[boring-cyborg]

Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.

Duplicate of #563

[scop]

Request seconded. What I'd like to see is be the ability to specify an exact version, or "greater-than-or-equal-to" version.

Exact version is obviously useful for maximum stablity/reproducibility, >= for cases where one wants to e.g. follow the latest with the GH action, while knowing that the config has been created with some lower version bound in mind, and wanting to communicate that for e.g. running locally.

For example, https://pkg.go.dev/github.com/Masterminds/semver/v3 contains features to parse and compare versions and constraints; could be applicable even though golangci-lint doesn't appear to follow semver fully. It provides all comparisons I think one can ask for.

[bombsimon]

One alternative could be to use the docker approach instead. Depending on your setup you can bump how golangci-lint is run at the same time as you bump the number in CI (if you have such). If you have the option to distribute a container you can just pin the golangci-lint version and every time someone runs docker run my-companys/golangci-lint they're running the same version as others and CI.

I get it's not ideal though. It's been mentioned before to have golangci-lint up- or downgrade itself and iirc it always ended with maintainers not wanting to go that path.

When I used to have this need and built a "version manager" for golangci-lint; gclv. It allows you to specify a version in .golangci.yml and use different version for different project. If the version isn't found it will first be downloaded before lining.

[aneeshusa]

What we do at my work is use https://pre-commit.com/ for this - a .pre-commit-config.yaml file in your repo pins the version of golangci-lint (as well as any other linters being used in the repo, e.g. we also use pre-commit for managing linters written in/designed for other languages). See #284 for more info about why we do this - been working great for the last 5 years!