You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cannot represent matching all files against multiple patternsΒ #423
The use-case seems like it would be quite useful and natural: I would like a label to apply if ALL of the changed files are of a few certain types. For example:
documentation:
- all: ["**/*.md", "**/*.puml"]
This of course doesn't work as all files need to match both patterns which never happens. Another attempt:
Hello everyone!
We've released a new beta version of the action with this feature on board. We would appreciate it if you could use the new version and share with us your feedback.
That looks like it satisfies this feature nicely! What's not clear from the documentation is what happens when multiple of AnyGlobToAllFiles, AnyGlobToAnyFile appear in a changed-files section. To all of them need to match for the label to be added, or any one of them? Or does the higher-level any: or all: answer that? It's not clear.
Hello everyone!
We have released the new major version of the action that includes the implementation of this feature. Please read the action documentation to find out how to adapt your configuration files and workflows for use with the new action version.
Thank you all for your patience!
Do not hesitate to contact us if you have any questions!
how would you accomplish the situation laid out in this issue with the new syntax? our goal is to avoid false positives when a bunch of files are changed in the PR that aren't actually relevant to the applied label
heres a table that I think describes where each of the existing rules fails in this use case
pattern
changed files
result
does not solve issue, because
any-glob-to-all-files: ['**/*.md', **/*.puml]
[test.md, test.puml]
no match
all files dont match any of the globs
any-glob-to-any-files: ['**/*.md', **/*.puml]
[test.md, test.puml, test.test]
match
test.test doesn't match any regex, but label is still applied
@jnew1 this is what I would expect for those four patterns you show:
match (both files find a pattern that matches)
match (test.md matches *.md, and that's all you need)
no match (there's no file matching *.puml)
no match (test.md doesn't match *.puml)
You wouldn't ever see a configuration like the last two, since they are impossible to ever be true. A more realistic case might be something like all-glob-to-all-files: ['README*', '*.txt'] where it's possible for a single file to match both patterns.
The globPatterns in that test match only paths containing at least one slash. foo.md won't match **/*.md but bar/foo.md will. To also match files in the root of the repo, you need to specify const globPatterns = ['*.md', '**/*.md', '*.puml', '**/*.puml'];
That test is similar to to the existing checkIfAnyGlobMatchesAllFiles test
but with two different file extensions in changedFiles. I would expect both
tests to pass, unless this matcher is supposed to be "ANY *one* glob must match
against ALL changed files" which doesn't sounds very useful (or intuitive).
Looks like you're right. I'd be up for renaming AnyGlobMatchesAllFiles to OneGlobMatchesAllFiles since that's what it does. Unless these semantics were used by mistake. I suspect the latter, because the current misnamed OneGlobMatchesAllFiles semantics could be implemented without it, in terms of AllGlobsMatchAllFiles, like:
Activity
ilya-lavrenov commentedon Jan 5, 2023
Why this does not work?
dfandrich commentedon Jan 20, 2023
My reading of the documentation is that that example is the same as:
This would add the documentation label to a PR consisting of 99 .c files and one .md file, which is not the intention.
Add the allofany matching type (actions#423)
Add the allofany matching type (actions#423)
dfandrich commentedon Jul 4, 2023
Just so it's explicitly clear, I have PR #487 outstanding that adds this feature.
silverwind commentedon Sep 11, 2023
See comment #487 (comment) which illustrates my idea of how this filter would work.
MaksimZhukov commentedon Sep 20, 2023
Hello everyone!
We've released a new beta version of the action with this feature on board. We would appreciate it if you could use the new version and share with us your feedback.
dfandrich commentedon Sep 20, 2023
That looks like it satisfies this feature nicely! What's not clear from the documentation is what happens when multiple of
AnyGlobToAllFiles,AnyGlobToAnyFileappear in achanged-filessection. To all of them need to match for the label to be added, or any one of them? Or does the higher-levelany:orall:answer that? It's not clear.MaksimZhukov commentedon Sep 21, 2023
Hello @dfandrich!
You are right, top-level keys (
anyandall) bind options (changed-files,base-branch, etc.), glob combinations (AnyGlobToAnyFile,AllGlobsToAnyFile, etc.) and regexps. I've updated the release notes.Thank you!
MaksimZhukov commentedon Dec 5, 2023
Hello everyone!
We have released the new major version of the action that includes the implementation of this feature. Please read the action documentation to find out how to adapt your configuration files and workflows for use with the new action version.
Thank you all for your patience!
Do not hesitate to contact us if you have any questions!
jnewb1 commentedon Dec 6, 2023
how would you accomplish the situation laid out in this issue with the new syntax? our goal is to avoid false positives when a bunch of files are changed in the PR that aren't actually relevant to the applied label
heres a table that I think describes where each of the existing rules fails in this use case
any-glob-to-all-files: ['**/*.md', **/*.puml]any-glob-to-any-files: ['**/*.md', **/*.puml]all-glob-to-any-files: ['**/*.md', **/*.puml]all-glob-to-all-files: ['**/*.md', **/*.puml]dfandrich commentedon Dec 6, 2023
@jnew1 this is what I would expect for those four patterns you show:
You wouldn't ever see a configuration like the last two, since they are impossible to ever be true. A more realistic case might be something like
all-glob-to-all-files: ['README*', '*.txt']where it's possible for a single file to match both patterns.jnewb1 commentedon Dec 7, 2023
unfortunently, the first case doesn't match
I think this test describes exactly the problem within this issue
for this to work,
any-glob-to-all-fileswould need to be something more likedfandrich commentedon Dec 7, 2023
The globPatterns in that test match only paths containing at least one slash.
foo.mdwon't match**/*.mdbutbar/foo.mdwill. To also match files in the root of the repo, you need to specifyconst globPatterns = ['*.md', '**/*.md', '*.puml', '**/*.puml'];jnewb1 commentedon Dec 8, 2023
same issue with this test
dfandrich commentedon Dec 8, 2023
jnewb1 commentedon Dec 8, 2023
yes that is exactly what it is
right
I believe I laid out a solution here: #423 (comment)
I can look at making a PR, but this would be an API breaking change, is it work making a new rule for it?
jnewb1 commentedon Dec 8, 2023
this new setup would break this test, which could be a legitimate use case:
https://github.com/actions/labeler/blob/8558fd74291d67161a8a78ce36a881fa63b766a9/__tests__/changedFiles.test.ts#L228C3-L239C6
so perhaps we just need a new rule
dfandrich commentedon Dec 8, 2023
Looks like you're right. I'd be up for renaming
AnyGlobMatchesAllFilestoOneGlobMatchesAllFilessince that's what it does. Unless these semantics were used by mistake. I suspect the latter, because the current misnamedOneGlobMatchesAllFilessemantics could be implemented without it, in terms ofAllGlobsMatchAllFiles, like:whereas the reverse is not true. There is no way to implement
AnyGlobMatchesAllFiles(the real one) in terms of the others.dfandrich commentedon Dec 29, 2023
FWIW, #731 was opened about the issue we've been discussing in the latter comments.