Support for exclusion paths
See original GitHub issueThere are cases where we want to match an entire directory but not certain subdirectories.
Instead of having to list each matching subdirectory, it would be nice to be able to exclude some paths from a match.
An example may be:
label1:
- match: "example1/**/*"
exclude: ["example1/foo/*", "example1/bar/*"]
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
Best Practices for Create Path-based Exclusions - SonicWall
This article provides a detailed overview on exclusion rules within Capture Client. These rules apply to path (file and folder) exclusions for all...
Read more >Add an exclusion to Windows Security - Microsoft Support
Select Add an exclusion, and then select from files, folders, file types, or process. A folder exclusion will apply to all subfolders within...
Read more >exclusionPaths | Apple Developer Documentation
exclusionPaths. An array of path objects that represents the regions where text doesn't display in the text container.
Read more >Excluded Paths | Acunetix
You can exclude specific parts of a web application from the scan by specifying paths to exclude based on regular expressions. For example: ......
Read more >UNC and system path variables support in the scan exclusion ...
Know if both Universal Naming Convention (UNC) path and system path variables are supported when configuring OfficeScan exclusion list.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
This seems like a helpful idea! I think we probably should be able to do something like this, I want to be careful here though - I don’t want to break existing configurations, so I don’t want to change the syntax of the
yml
file.I think a better approach might be to support
!
as a negate pattern. So you’re example would look the following instead:Probably, we’d want to evaluate sequentially until we find a pattern that matches. So that way we could even do something like:
The above example would not match
example2/foo/bar/abc.txt
, would matchexample2/foo/baz/abc.txt
, would not matchexample2/notFoo/baz/abc.txt
, and would matchnotExample2/foo/baz/abc.txt
since the patterns are evaluated in order - I think this would be about as powerful as we can get.Thoughts?
@fluzzi discussion is taking place in #22. However, I think I can support your use case if the maintainers are willing to accept my
map
configuration proposal.Your use case could be represented as: