Description
After my PR introducing the optimized file-globbing path (#2884), Task now
matches hidden entries when a pattern takes that path and does not match them
when the pattern uses the fallback path.
I understand that not matching names beginning with . comes from traditional
Unix shell glob behavior, but it feels surprising that **/* does not mean
every file below that directory when it is used for Task sources.
This matters for caching. In my project, I had inputs beginning with . that I
expected to be matched. A familiar example would be .env: if it affects a
task and changes, I would expect the source fingerprint to change too. Whether
a file participates in the cache key should not depend on which internal
globbing path handles the pattern.
Exclusions can have the same inconsistency. An optimized inclusion can find a
hidden file that a fallback exclusion then fails to remove.
I see two possible directions:
- Restore the previous behavior by making the optimized path skip hidden
entries.
- Go forward with recursive source globs including hidden entries consistently
in both paths.
My preference is the second option. "Hidden" is mostly a naming and display
convention; it does not mean that a file cannot affect a task. However, this
would intentionally change the older behavior, so I would appreciate input
before implementing it.
I have a tests-only draft that exercises both paths, including hidden files,
hidden directories, exclusions, and their effect on source fingerprint caching.
Version
nightly / main at 75b227e. The inconsistency was introduced by 9200d42
(#2884).
Operating system
Observed on Linux. The two globbing paths themselves are platform-independent.
Experiments Enabled
None.
AI assistance
I used Codex to help develop and validate the tests. I reviewed and understand
the changes and this report.
Description
After my PR introducing the optimized file-globbing path (#2884), Task now
matches hidden entries when a pattern takes that path and does not match them
when the pattern uses the fallback path.
I understand that not matching names beginning with
.comes from traditionalUnix shell glob behavior, but it feels surprising that
**/*does not meanevery file below that directory when it is used for Task sources.
This matters for caching. In my project, I had inputs beginning with
.that Iexpected to be matched. A familiar example would be
.env: if it affects atask and changes, I would expect the source fingerprint to change too. Whether
a file participates in the cache key should not depend on which internal
globbing path handles the pattern.
Exclusions can have the same inconsistency. An optimized inclusion can find a
hidden file that a fallback exclusion then fails to remove.
I see two possible directions:
entries.
in both paths.
My preference is the second option. "Hidden" is mostly a naming and display
convention; it does not mean that a file cannot affect a task. However, this
would intentionally change the older behavior, so I would appreciate input
before implementing it.
I have a tests-only draft that exercises both paths, including hidden files,
hidden directories, exclusions, and their effect on source fingerprint caching.
Version
nightly/mainat 75b227e. The inconsistency was introduced by 9200d42(#2884).
Operating system
Observed on Linux. The two globbing paths themselves are platform-independent.
Experiments Enabled
None.
AI assistance
I used Codex to help develop and validate the tests. I reviewed and understand
the changes and this report.