[FR]: Ignore linting via `.gitattributes`

[stevendee-recon]

What is the current behavior?

Putting rules-lint-ignored=true in .gitattributes excludes files from formatting, but lint errors still show up in aspect lint.

Describe the feature

It'd be nice if linting could also respect .gitattributes, either with the same annotation or a different one.

Alternatively, having a way to pass the no-lint tag to all subpackages, or to instruct gazelle to emit this tag in subpackages, would be nice.

The goal being achieved here is to exclude e.g. //users (or //vibe) from linting by default; it may not even be a well-formed goal, so I will also happily accept better goals as resolutions for this FR.

[alexeagle]

I think .gitattributes is tricky for controlling which things are linted, because it governs files, while linting is an operation over targets. Someone would have to do a bazel query to figure out which files are sources of which targets. Then there's the question of whether you lint a library when some of its sources are "ignored" via .gitattributes but others are not.

As one option, when you run the linter over the repo you could just adjust the target pattern like bazel build [flags] -- //... -//users/... -//vibe/... - you'd need to do this if you want to exclude errors from linters.

If you only need to exclude warnings, you could just do this in whatever presentation layer is showing the lint reports. If you're using Aspect CLI, we could add a filtering mode based on .gitattributes I think.

[stevendee-recon]

That makes sense.

We are indeed using Aspect CLI; a filtering mode based on .gitattributes would tidily solve the problem.

What about a Gazelle directive?

That said it’s becoming shockingly easier to semi-automatically fix lint errors, so it’s unclear how crucial this FR even is.

[stevendee-recon]

Hrm, it also looks like aspect lint does not accept multiple targets; although the help says [targets], only one is allowed:

error: unexpected value '//vibe/...' for '[targets]' found; no more were expected

[stevendee-recon]

Ah, the [targets] arity looks to have been fixed by 76b119b.