Golangci-lint: Debug why a private linter was not added to the list

[alexisvisco]

Hi, I am using a private linter but it doesn't appear in the list of linters.

• I have checked the dependencies list to make sure all versions are the same as the golang ci 1.29 (http://github.com/alexisvisco/logwercase).
• My .golang-ci.yml is like that:

linters:
 enable:
   - unparam
   - misspell
   - godox
   - gocritic
   - scopelint
   - golint
   - unconvert
   - gofmt
   - exportloopref
   - govet
   - bodyclose
   - gosimple
   - goconst
   - gosec
   - logwercase

linters-settings:
  custom:
    logwercase:
      path: /home/aviscogl/go/bin/logwercase.so
      description: Analyze case of log message and WithField keys
      original-url: github.com/alexisvisco/logwercase

There is an option to known why a private linter is not added? https://golangci-lint.run/contributing/debug/ Does not help me ...

[boring-cyborg[bot]]

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

[sayboras]

@alexisvisco thanks for your issue. I just quickly tried, seems like it's showing for me. Can you share your steps ?

$ ./golangci-lint linters
Enabled by your configuration linters:
...
gomnd: An analyzer to detect magic numbers. [fast: true, auto-fix: false]
goprintffuncname: Checks that printf-like functions are named with `f` at the end [fast: true, auto-fix: false]
gosec (gas): Inspects source code for security problems [fast: true, auto-fix: false]
gosimple (megacheck): Linter for Go source code that specializes in simplifying a code [fast: true, auto-fix: false]
govet (vet, vetshadow): Vet examines Go source code and reports suspicious constructs, such as Printf calls whose arguments do not align with the format string [fast: true, auto-fix: false]
ineffassign: Detects when assignments to existing variables are not used [fast: true, auto-fix: false]
interfacer: Linter that suggests narrower interface types [fast: true, auto-fix: false]
lll: Reports long lines [fast: true, auto-fix: false]
logwercase: Analyze case of log message and WithField keys [fast: true, auto-fix: false]
misspell: Finds commonly misspelled English words in comments [fast: true, auto-fix: true]
nakedret: Finds naked returns in functions greater than a specified function length [fast: true, auto-fix: false]

$ ./golangci-lint linters | grep -is logwercase
logwercase: Analyze case of log message and WithField keys [fast: true, auto-fix: false]

[alexisvisco]

Strange, I was not using the right config, unfortunately, it does not work as you because I get an output from golangci:
ERRO Unable to load custom analyzer logwercase:/home/aviscogl/go/bin/logwercase.so, plugin: not implemented

I don't know why it's outputting that because you were able to add it :thinking:

[sayboras]

Might be related to version. I used master branches with one small changes to make sure same x/tools version in your tool and golangci-lint. With your above config, I just ran the check.

Can you share version details as well?

[alexisvisco]

I was pretty sure the exact same versions are present...

golangci-lint has version 1.29.0 built from 6a68907 on 2020-07-20T14:54:31Z

[sayboras]

You are right, seems like there is some issue with v1.29.0. I didn't see any related commits, which could affect this one.

Can you try with master branches (in golangci-lint and in your logwercase) as well ?

[mattysweeps]

I am experiencing the same behavior.
When I build golangci-lint from the master branch (60613dc3eb841f9d3a07dcc2c59e96eefdfc428f) my custom plugin works just fine.
When I use the docker images for versions 1.27, 1.28, and 1.29, I get the plugin: not implemented error.

Update:
I just built from the v1.29.0 tag and everything worked fine. I wonder if the problem might be in the way the release binary is being created? Something that disables plugin use?

[mattysweeps]

This might be related: https://github.com/golang/go/issues/19569

[mattysweeps]

Looks like CGO_ENABLED is the culprit.

| golangci-lint | my plugin | result |
| --- | --- | --- |
| CGO_ENABLED=1 | CGO_ENABLED=1 | Success |
| CGO_ENABLED=0 | CGO_ENABLED=1 | Failure plugin: not implemented |
| CGO_ENABLED=1 | CGO_ENABLED=0 | Cannot build plugin loadinternal: cannot find runtime/cgo |
| CGO_ENABLED=0 | CGO_ENABLED=0 | Cannot build plugin loadinternal: cannot find runtime/cgo |

So custom plugins will never work with release versions because the release binary is compiled with CGO_ENABLED=0
Same goes for the docker images, since they also use a CGO_ENABLED=0 binary.

However, the docker images could work if the golangci-lint binary in them was compiled with CGO_ENABLED=1
Then users could create their own docker images which extend the golang-ci image and add the custom plugins as well.
Note that the custom plugins should probably be compiled as part of the build process for the customized docker image, to avoid using plugins which were created for different architectures (darwin)

[sayboras]

@mattysweeps thanks for your detailed explaination. You are right, the release binaries are built with CGO_ENABLED=0 only. This might be something we can improve.

[alexisvisco]

Should the binary produced during the installation of golanci-lint not by default support plugins since it is a feature of the linter?

[sayboras]

Should the binary produced during the installation of golanci-lint not by default support plugins since it is a feature of the linter?

Yeah, I am completely agreed with you. Just found related issue here https://github.com/golangci/golangci-lint/issues/1182 though.

[sayboras]

@alexisvisco seems like there is nothing we can do here, except update docs :). Please let me know if it's fine.

[draveness]

@alexisvisco seems like there is nothing we can do here, except update docs :). Please let me know if it's fine.

I encountered the same problem when dealing with golangci-lint custom plugin feature.

so for private linter, we have to build the golangci-lint with CGO_ENABLED=1 flag from source code to leverage this feature. But I think the extra step breaks the feature since the purpose of go plugin is to load packages without rebuilding the main binary. If we have to rebuild it, why not create a intree plugin instead of the custom one. Please correct me if there's something wrong. :)