Add support for remote config file

[alexandrevilain]

your feature request related to a problem? Please describe.

When working in a multiple services environnent it can be hard to maintain and to update lint rules at the team/project level.

When a library is no more maintained or with a big security issue, adding the rule to stop using it for each project can be pretty time consuming.

Describe the solution you'd like.

Maintaining a single repository with lint rules for the project/team.
With a CI/CD pipeline pushing the latest rules to an S3 bucket , nexus repository or something else.

Then for each project/service the Makefile would be like:

.PHONY: lint
lint:
   golangci-lint run --config=https://team.repository.com/lint/.golangci-lint.yaml

Describe alternatives you've considered.

• Using git submodules: It become as time consuming as updating the configuration file for each services,
• Cloning the repository for each CI pipeline to retrieve the lastest configuration file: Developpers needs to do it on their dev computer too, bad dev experience.

Additional context

Here is the implementation pull request: #2136

[boring-cyborg]

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

[bombsimon]

Would it make sense to get the config as a dependent macro? You could make it .PHONY as well if you want to download it each time.

/tmp/.golangci.yml:
  curl https://team.repository.com/lint/.golangci-lint.yaml --output /tmp/.golangci.yml

.PHONY: lint
lint: /tmp/.golangci.yml
  golangci-lint run --config=/tmp/.golangci.yml

[alexandrevilain]

Hi! Thanks, that's a good workaround!

Wouldn't be easier to get it integrated inside golangci-lint or is it out of scope ?

[ldez]

Every remote interaction is a possible security issue, it would be better to not embed this kind of remote access in the binary.

[SVilgelm]

also, the reading remote file requires some additional configuration options:

• custom CA certificate
• ignoring TLS
• timeout
• custom http headers

it is really better to download the config file by curl

[SVilgelm]

also it would be great to support git protocol

[thepwagner]

Does #2241 satisfy these use cases?

If you want to use curl, it should make combining the "team" settings with any local overrides easier.

It also adds the option of fetching the configuration from a referenced go module, which means git support, digest pinning, etc. Go modules has the advantage of pushing lint configuration changes out via tools like Dependabot - having a "your team changed lint settings, here's what it does to your build" PR would be slick.

[bombsimon]

Is this close enough? #2618

You should be able to run golangci-lint run --config <(curl https://team.repository.com/lint/.golangci-lint.yaml).

It assumes you have curl installed but I don't think that's a weird assumption given you have to have the whole Go toolchain available for golangci-lint itself to run.

[donotnoot]

Nice, good to see I wasn't the only one missing this feature. I didn't see this issue when I sent the PR for process substitution to work yesterday. FWIW I absolutely agree that golangci should not attempt to fetch files itself from remote sources :)

Just a tip, if you need to use a token to access github like I do for work the command can be written like this:

golangci-lint run --config <(curl -H"Authorization: Token {your PAT}" -sL 'https://raw.githubusercontent.com/work-org/linter-rules/master/rules.yaml')

[thepwagner]

Thanks for landing this 🎉

From my previously linked PR:

• I thought the ability to combine configurations was worthwhile. For large organizations, it's common to have a global standard that individual repositories customize. Linters like gci and goimports aren't useful with a single shared global configuration
• I thought leveraging the go modules system for distribution was interesting. For large organizations, updating the rules in https://team.repository.com/lint/.golangci-lint.yaml will immediately impact projects fetching the configuration via curl. To avoid breaking builds, I'd need to publish https://team.repository.com/lint-v2/.golangci-lint.yaml and then ask projects to migrate to the new rules. Go modules offers versioned distribution via familiar tooling.

Any workaround ideas, or am I still waiting for #1141 ?

[donotnoot]

If you're using github for example (I'm sure other git services can do something similar), you could always pin the linter rules to a tag or branch etc.:

golangci-lint run -c <(curl https://raw.githubusercontent.com/org/linter-rules/{tag}/rules.yaml)

Sure, that's less sophisticated than go modules (and maybe that's for the better lol) but it should get the job done and not break the rules when updates happen upstream.

You could also use a tool like yq to merge a custom yaml into the base yaml (https://mikefarah.gitbook.io/yq/v/v2.x/merge) and have that passed in via stdin to golangci or use process substitution etc. now that it works. Personally I think keeping the tool simple and leveraging the environment in which it runs is a better approach than making the tool do more. Unix blah blah blah...