GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||||
GeezerVison is showing github.com — Implement -IncludeSuppressions parameter by rjmholt · Pull Request #1701 · PowerShell/PSScriptAnalyzer Conversation
|
|
Ok, I've spent ages trying to debug this but it doesn't make any sense. The new parameter sets aren't present, but the command is loaded from the asset location, and this only happens in WinPS 5.1... |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I finally worked this out. We have a bizarre test that overrides |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| WriteToOutput(diagnosticsList); | ||
| if (fix) | ||
| { | ||
| ShouldProcess(path, $"Analyzing and fixing path with Recurse={this.recurse}"); |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Is this a bug with the original code? If I read this correctly we will take the action no matter what, but ShouldProcess is supposed to notify the user and not take the action in the case of -WhatIf. this code will fix the script even with -WhatIf. I get that it's not as big a deal for just the diagnosis part, but the fix part seems wrong.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Yeah I saw this and had the same thought. Definitely something we should review. If Christoph Bergmeister (@bergmeister) agrees, I can open an issue to track it so we can fix it beyond this PR.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
This goes back to my very first PR in PSSA, where I added the -Fix switch and since this is an action that changes state, I implemented ShouldProcess for it and declared that on the cmdlet. Since the -Fix parameter is only on the -File parameter set, I did not implement it for the -ScriptDefinition parameter set. Original commit is here: bfa1c54
Therefore I still think it's not really important here, very rarely does one run PSSA where the command would take ages and performing a dry-run would save time. Still happy to have a tracking issue
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| public SuppressedRecord(DiagnosticRecord record, IReadOnlyList<RuleSuppression> suppressions) | ||
| { | ||
| Suppression = new ReadOnlyCollection<RuleSuppression>(new List<RuleSuppression>(suppressions)); | ||
| IsSuppressed = true; |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Could this ever be called with a suppression list count of zero? In that case IsSuppressed really true?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Very good question. I think the mere wrapping in the SuppressedRecord object classes the diagnostic as suppressed, but I agree that this opens up the possibility of an invalid object, which I dislike... I'm not sure I see a way around this without changing a few things around though, and I'm not sure that's worth it.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good but not sure whether doubling the parameter sets is the right way. This can make the experience more confusing for users and makes maintenance more complicated as well. How about an Enum parameter instead that has a default?
Some good improvements to tests that made some assumptions :-)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
So I would prefer an enum parameter, but that would be a breaking change; invocations that previously use In order to keep |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Hmm, didn't realize Having said that, this topic is opinionated and I am sure the other side will argue for param sets with its early validation before actually running the command. Therefore I suggest we let a 3rd person like James Truher (@JamesWTruher) decide on this matter. I am happy with the rest of the PR. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Rob Holt (@rjmholt) Christoph Bergmeister (@bergmeister) i'm generally in favor of adding parameter sets where they make sense and don't over complicate things. In this case we're going from 2 to only 4 so i don't believe it's a higher cognitive load. The benefit with parameter sets is that we can determine behavior via inspection rather than runtime, so tools like vscode provide a better experience. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
c970e73 to
02ccd84
Compare
|
Christoph Bergmeister (@bergmeister) James Truher (@JamesWTruher) need an approval to merge 🙂 |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.