Support for exclusion paths

[jalaziz]

There 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/*"]

[damccorm]

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:

label1:
- "!example1/foo/*"
- "!example1/bar/*"
- "example1/**/*"

Probably, we'd want to evaluate sequentially until we find a pattern that matches. So that way we could even do something like:

label2:
- "!example2/foo/bar"
- "example2/foo/**/*"
- "!example2/**/*"
- "**/*"

The above example would not match example2/foo/bar/abc.txt, would match example2/foo/baz/abc.txt, would not match example2/notFoo/baz/abc.txt, and would match notExample2/foo/baz/abc.txt since the patterns are evaluated in order - I think this would be about as powerful as we can get.

Thoughts?

[jalaziz]

I don't want to break existing configurations, so I don't want to change the syntax of the yml file.

Actually, that's exactly why I proposed the syntax above. Maps aren't currently handled and it should be possible to support existing configuration files without breaking them.

I had thought about negation, but my fear is that it would cause confusion with the semantics of the list as it stands today. Today the label is applied if any path matches. Should negation mean that a non-match should receive the label? Or that we should stop searching? It would also mean that the order of the rules matter. That's why I figured it would be better to be explicit with a map.

That being said, if you're comfortable with order being significant, then I'd certainly prefer your proposed syntax. It's certainly simpler than what I proposed!

[damccorm]

Actually, that's exactly why I proposed the syntax above. Maps aren't currently handled and it should be possible to support existing configuration files without breaking them.

Ah I see, that makes sense - at the same time, I don't think I want us to support 2 different syntaxes if possible though - that leads me to prefer an additive pattern if possible

if you're comfortable with order being significant

I actually think this is a pretty common pattern that I've seen elsewhere. I think as long as we doc it, it should be fine. I think it makes intuitive sense as well (at least to me 😄).

[jalaziz]

@damccorm took a stab at this. Testing against a local repo has proven to provide the flexibility we need.

[fluzzi]

i'm trying to use this to match only if specific file is changed, but not if that specific file and another one are modified but dosn't seem possible with this change.

the idea would be to add the label only if all the files match the pattern, is that possible?

[jalaziz]

i'm trying to use this to match only if specific file is changed, but not if that specific file and another one are modified but dosn't seem possible with this change.

the idea would be to add the label only if all the files match the pattern, is that possible?

@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:

label1:
- match: "example1/foo"
  exclude: ["example1/bar"]