Description
The Problem
Larger repos may contain logically distinct components that are built into separate artifacts. For instance, https://github.com/grafana/loki/tree/main/cmd contains various utilities that are built and packaged into separate binaries.
Right now, it is only possible to specify a set of rules for the entire repository; ideally I'd like to be able to specify different rulesets for different paths-- the motivating example here is that the CLI tools in loki produce a large number of command and filepath injection warnings by virtue of being CLI utilities intended to accept user input. If possible, I'd love to at least temporarily suppress these warnings in CI without adding a ton of annotations.
Proposed Solutions
(I'm happy to do the legwork on implementation if the maintainers agree one of these seems good)
- Add an option for filtering issues from output based on path+ruleID. Quick and easy to implement, but it'd be an extra field in the configuration for a niche use case. Could be built as an extra loop at the issue filter stage in
main.go
. - Add a notion of
path
based configuration blocks: at the top level of the JSON config, add anoverrides
key, whose value is a list of nested configuration blocks that have the same semantics as a top level config json file, but only apply to a specific path set. This is a lot more flexible in terms of enabling other behaviors eventually, like tuning rule parameters per-path, but its' also more work to build, and might not play nicely with current configuration handling for rules without some changes.
Implementation for (2) would probably look like a few changes tomain.go
to construct and execute multiple analyzers in a loop, one for each override path and one for the global config, minus overridden paths. - Something else? Happy to chat about what you think would be useful for the project :).