[FR]: lint Go code

[alexeagle]

What is the current behavior?

With #207 we no longer have any Go linters.

Describe the feature

#137 and #129 were bugs when golangci-lint was in this repo, those need to be solved for a roll-forward.

[mrmeku]

In prior projects, I've used the github action provided by golang ci lint itself which supports its own only report only new issues implementation via only-new-issues: true. I wonder if that strategy can be applied here. Let the linter have access to all source files but cull the reported errors to just those affected by a git diff.

[alexeagle]

Doesn't work with our design here that lints are just actions that visit the go_library graph and rely on Bazel's action caching (and remote execution).
Having git information available to the linter would make it non-hermetic and not follow that design.
But let's chat, maybe there's a middle path here I'm not seeing.

[ewhauser]

I think it is worth trying to run a nogo binary as rules_lint compatible linter as opposed to trying to coerce golangci-lint to work in a Bazel way. You can run all the same analyzers with nogo that you can run under golangci-lint.

This is the approach that gVisor takes: https://github.com/google/gvisor/blob/master/tools/nogo/defs.bzl

[alexeagle]

Ooh that example should be really helpful, thanks!

[aaomidi]

This is one of our primary issues adopting bazel at the moment. We've kinda started wrapping around most of the golangci-lint linters (and, unfortunately, it's really hard to get the exact golangci-lint behavior by just doing this, since there's a lot of sensible defaults golangci-lint applies)

[ewhauser]

Have you tried https://github.com/sluongng/nogo-analyzer? It gets you very close to what golangci-lint does using the same analyzers.

[aaomidi]

I have, unfortunately its not really what I'm looking for. For example: https://github.com/sluongng/nogo-analyzer/blob/master/goci-lint/errcheck/analyzer.go just brings in the errcheck analyzer, which isn't exactly what the golangci-lint project is doing.

Beyond that I think that's not a bzlmod yet, which makes consuming it for our team a bit more difficult.

Honestly, I also much prefer how aspect rules_lint works compare to how nogo does it. I feel like given enough linters, nogo is going to really slow down builds.

Also, no autofix support :(

[derekperkins]

We'd love to move golangci-lint to bazel, but continue to run the GitHub Action in the meantime. 🤞

• Add Native Support for Bazel nogo golangci/golangci-lint#1473
• Support golangci-lint via nogo bazel-contrib/rules_go#2695