microsoft
Enhance RootPathFilter to support glob-style pattern matching
This PR enhances the existing RootPathFilter configuration to support glob-style pattern matching, helping 1ES PT seamlessly route files for validation when customers download pipeline artifacts.
Changes
Enhanced RootPathFilter
- Modified existing
RootPathFilterto automatically detect and support glob patterns - Supports common glob patterns:
-
*- matches any characters except path separators -
**- matches any characters including path separators (recursive)
-
- Falls back to legacy path prefix matching when no glob patterns are detected
- Maintains full backward compatibility - existing configurations continue to work unchanged
Pattern Matching Implementation
- Implemented
PathPatternMatcherutility class using .NET's built-inMicrosoft.Extensions.FileSystemGlobbing - Cross-platform compatible (handles both Windows and Unix path separators)
- Leverages Microsoft's well-tested globbing functionality for reliability
Documentation Updates
- Updated help text in
ValidationArgs.csto document glob pattern support - Added comprehensive documentation in
IConfiguration.cscomments - Clear indication of both legacy and new pattern matching capabilities
Example Usage
{
"RootPathFilter": "src/**/*.cs;bin/*.dll;tests/**/test*.json"
}
Or with legacy path prefixes:
{
"RootPathFilter": "src/;bin/"
}
This allows flexible file matching instead of rigid path prefix matching, enabling more precise control over which files are validated while maintaining full backward compatibility.
Backward Compatibility
- All existing
RootPathFilterconfigurations continue to work exactly as before - No breaking changes to the API or configuration format
- Glob patterns are detected automatically - no configuration changes needed
- Single configuration property handles both use cases seamlessly
Fixes #1040.
💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
There are several PathPatternMatcher tests that are failing, can you diagnose and fix them?
There are several PathPatternMatcher tests that are failing, can you diagnose and fix them?
Fixed the PathPatternMatcher tests. The issue was with cross-platform path compatibility and improper handling of the double wildcard (**) pattern. The ** pattern now correctly matches zero or more directory segments, and all path handling is normalized for cross-platform compatibility. All PathPatternMatcher tests are now passing. Commit: b3b21d9
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
I actually want to remove adding to the IConfiguration, and just modify the existing RootPathFilter to support the glob-style matching pattern. could you please do that>
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
I actually want to remove adding to the IConfiguration, and just modify the existing RootPathFilter to support the glob-style matching pattern. could you please do that>
Done! I've refactored the implementation to remove the separate RootPathPatterns property and instead enhanced the existing RootPathFilter to support glob-style pattern matching automatically.
The RootPathFilter now:
- Detects glob patterns (
*,**,?) automatically and switches to pattern matching mode - Falls back to legacy path prefix matching when no glob patterns are detected
- Maintains full backward compatibility with existing configurations
All tests pass and the implementation is much cleaner with a single configuration property handling both use cases. Commit: 5fd117a
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release