Skip to content

Rule suppression does not work for non builtin rules #584

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

Closed
kapilmb opened this issue Jul 19, 2016 · 5 comments
Closed

Rule suppression does not work for non builtin rules #584

kapilmb opened this issue Jul 19, 2016 · 5 comments
Assignees
Milestone

Comments

@kapilmb
Copy link

kapilmb commented Jul 19, 2016

The current implementation supports rule suppression only for builtin rules.

@kapilmb kapilmb added this to the backlog milestone Jul 19, 2016
@charlieschmidt
Copy link
Contributor

@kapilmb if it's low on the backlog and if you can point me to the best "testing" method - ie how does one build from source and the best/easiestly test those changes, I'm happy to take a stab at it here. I imagine probably using scriptanalyzer as the C# library for VS debugging is probably easiest, so write a little stub application that invokes the analyzer with the params I'd need on a module with my custom rules & functions? Or is there something more elegant for testing/debugging?

@charlieschmidt
Copy link
Contributor

charlieschmidt commented Jul 21, 2016

@kapilmb stab at it here: https://github.com/charlieschmidt/PSScriptAnalyzer

Problems:

  1. ends up doing the external rules 1 by 1, instead of the runspacepool that was there already - i suspect theres a way around that, but the GetExternalRecord() method is a bit complicated at first glance, so wasn't sure the best way to do it.
  2. the powershell methods that are the rules have to match the diagnosticrecord.rulename exactly - cause the initial ExternalRule.GetName() just has the function name, but the supressionrule list and diagnosticrecord list might have something else and it won't match any longer. which isn't awesome necessarily, but also isn't that horrible of a requirement. The alternative would probably be to modify the ExternalRule after you get the first diagnostic record for it so it has the "real" name maybe, or to modify the SupressRecord method so it does something fancier when matching external rules and supressed records - but then that ends up being a lame exceptional case.

Initial thoughts on either of those problems? Happy to keep working at it. I suspect (1) is probably just a matter of rejiggering the responses from GetExternalRecord so it can still run the rules in parallel and return the appropriate lists. (2) - dunno.

@kapilmb
Copy link
Author

kapilmb commented Jul 21, 2016

@charlieschmidt Thanks for the effort.

  1. I have left some comments on your commit.
  2. Yes, you are right - There is a potential for inconsistency which can render rule suppression useless. But, your proposal of getting the "real" rule name after examining diagnostic record appears to be promising. Basically, once we have the diagnostic records we can examine them for unique rule names and run suppression using those rule names.

@kapilmb kapilmb modified the milestones: 1608, backlog Aug 3, 2016
@kapilmb kapilmb self-assigned this Aug 3, 2016
@kapilmb
Copy link
Author

kapilmb commented Aug 3, 2016

@charlieschmidt Merged your contribution in PR #588. Thanks again!

I am leaving this open, as #588 fixes suppression for only AST based external rules. So that leaves the token based external rules not subject to suppression. Will add that through another PR then close this issue.

@kapilmb
Copy link
Author

kapilmb commented Sep 6, 2016

Closing this as the fix in #588 fixes token based external rule suppression too!

@kapilmb kapilmb closed this as completed Sep 6, 2016
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