[Bug]: golangci-lint doesn't pull in dependencies

[jelmer]

What happened?

golangci-lint doesn't just look at the .go file specified on the command-line, it also needs to pull in metadata about e.g. types from other files that are referenced from the file that is being linted. Without this, it complains about missing files.

The lint target should inherit all dependencies of the original target, as well as dependencies on any generated files in srcs as those are currently being filtered out (since they don't newed to be linted).

Version

Development (host) and target OS/architectures:

Output of bazel --version:

bazel 7.0.2

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:

N/A, reproducible using example from rules_lint

Language(s) and/or frameworks involved:

Go / golang-ci

How to reproduce

I'll attach a PR to this bug that demonstrates the issue with the example in the rules_lint repo.

Any other information?

No response

[srabraham]

ah, I missed the fact that @jelmer already made a PR that demonstrated this... here's my unnecessary demonstration of this as well. #145
FYI @alexeagle. This bug makes rules_lint effectively unusable for golangci-lint

[alexeagle]

Taking a look at this finally. I added a commit on #145 which adds these missing files to the inputs of the action - but that's not enough because Go expects the files to be in $GOROOT/pkg/gopher or something. It seems like rules_go does some shenanigans to make these resolve, will require some more study.

In the meantime I'm tempted to remove golangci-lint from rules_lint until we have something that works for this case, WDYT?

[jelmer]

I agree that's probably better than having it half-work and having people try it until they stumble over this bug.

@psalaberria002 might have thoughts as well, since IIRC he originally added this support and might have opinion on whether it's useful to keep with this bug present.

[psalaberria002]

I agree that's probably better than having it half-work and having people try it until they stumble over this bug.

@psalaberria002 might have thoughts as well, since IIRC he originally added this support and might have opinion on whether it's useful to keep with this bug present.

Ok with reverting it until it's fully supported. We are currently using nogo instead.

[alexeagle]

@mgechev I know you've got bigger fish to fry, but in case you'd like to come play in Bazel-land, I'd love to have golang supported here!