-
Notifications
You must be signed in to change notification settings - Fork 965
Description
What would you like to be added?
- Ignoring hidden files should be mentioned around "Using a wildcard pattern", not hidden away from the examples in just the breakdown of input options.
- When an upload ignores an otherwise hidden file, at least a "notice" should be served on the log of the action, instead of going down the usual "no files found" path with its set error handling.
- In case the
pathspecified is explicitly pointing to a single file that does exist but is hidden, this "notice" should be elevated to an "error". In both cases, the developer reading the logs should be pointed at this option in order to enable it. - (Alternatively, if the
path:specifies a single file to be uploaded, it should be respected even if it is "hidden".)
- In case the
Why is this needed?
I was adding the archival of a "hidden" file named .ninja_log into our workflows to debug a blanket slowdown that appeared in our project. It took me the better part of a day (FTE) to figure out why upload-artifact wasn't working as it should. Something like 12 retries of a rather slow and expensive workflow (30+ minutes on a MacOS runner!) led me to the resolution. We usually don't upgrade action versions unless necessary or when already touching around those parts in the codebase, so I upgraded from v4.2.0 to both v5.0.0 and then v4.4.0. I would have never imagined that a minor version upgrade would introduce such a breaking change in the first place.
It's a bit dumbfounding to see that (especially after trying various combinations like relative paths, absolute paths, wildcards, getting the path as an output variable or an env variable and reusing that in the with:, etc.)
- run: |
ls -alh Build-*/.ninja_log
- uses: actions/[email protected]
with:
path: Build-*/.ninja_log
reports that "no files were found" from the action, while the simple shell script running in the same context clearly shows that the file exists. It paints a picture as-if the two steps were not reading the same room, causing odd debugging cycles and, as mentioned above, somewhat expensive round-trips during that debugging. There should be a clear distinction between "the file doesn't exist" or "the file exists but can't be read" (external property of the file itself irrespective of the action itself) and "the file exists, I just refuse to handle it, unless you enable this toggle..." (internal property that the action imposes upon itself, and only itself), and this should be better respected and communicated.