You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 an overrides 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 to main.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 :).
The text was updated successfully, but these errors were encountered:
Thanks for this proposal, it can be a useful feature. I tend towards option 1. I would probably add an option such as filter which can accept a YAML/JSON configuration with a list of rules to be excluded per path. We can just filter the output based on this configuration. WDYT?
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)
main.go
.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 to
main.go
to construct and execute multiple analyzers in a loop, one for each override path and one for the global config, minus overridden paths.The text was updated successfully, but these errors were encountered: