-
Notifications
You must be signed in to change notification settings - Fork 157
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
Add path based rules and pester tests #3182
Conversation
foreach ($rule in $pathBasedRules.Keys) { | ||
foreach ($rulePath in $pathBasedRules[$rule]) { | ||
if ($runAll -or $root.PathExists($rulePath)) { | ||
$variables += $rule |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what happens if you have 2 paths for the same variable? Would we set that variable twice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The break;
below pops us out of the "path" forEach back into the "rule" forEach. So we should only add a rule name once after we find the first matching path for the rule
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rule name is the variable name, so we wouldn't have 2 rules with the same variable name
98e7399
to
01efb1c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall I don't think this change is an improvement in readability / debugability. Reading a bunch of regex's is not exactly intuitive and unless we have perfect unit tests we will miss quite a few things.
$this.RunVariable = $runVariable | ||
$this.RunValue = $runValue | ||
} | ||
$runAll = @('^eng/common/') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is more to run all than this, there was a recent pr which added some.
# exclude paths start with '!' | ||
$pathBasedRules = @{ | ||
'RunEng' = @('^eng/common/scripts/') | ||
'RunCSharp' = $runAll, '^packages/http-client-csharp', '^\.editorconfig$' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should editorconfig trigger all emitters?
'RunJava' = $runAll, '^packages/http-client-java/' | ||
'RunTypeScript' = $runAll, '^packages/http-client-typescript/' | ||
'RunPython' = $runAll, '^packages/http-client-python/' | ||
'RunCore' = @( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is more than should be excluded here around eng/emitter stuff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh this PR does a similar thing how I was gonna rewrite that in TS to reuse the same label config. Difference is I am just using standard gitignore wildcard pattern which I think is easier to maintain than regex for paths.
import { AreaPaths } from "./areas.js";
/**
* Path that should trigger every CI build.
*/
const all = ["eng/common/", "vitest.config.ts"];
export const CITriggers = {
"http-client-csharp": [...AreaPaths["emitter:client:csharp"], ...all],
core: [
"**/*",
"!.prettierignore",
"!.prettierrc.json",
"!cspell.yaml",
"!esling.config.json",
...ignore(AreaPaths["emitter:client:csharp"]),
],
};
Add vi.config.ts to runAll
I like the look of the minimatch patterns more that the regex. I'll close this PR |
fixes #3181