Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apply different rule sets to different paths #1287

Open
dannyc-grafana opened this issue Jan 14, 2025 · 2 comments
Open

Apply different rule sets to different paths #1287

dannyc-grafana opened this issue Jan 14, 2025 · 2 comments

Comments

@dannyc-grafana
Copy link
Contributor

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)

  1. 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.
  2. 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.
  3. Something else? Happy to chat about what you think would be useful for the project :).
@ccojocar
Copy link
Member

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?

@dannyc-grafana
Copy link
Contributor Author

That works for me-- its a much simpler implementation TBH. I'll get to work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants