Repository navigation
ENOENT: no such file or directory while attempting to upload #240
Description
Describe the bug
We're using upload-artifact to upload our packages as part of our workflow. This has, historically, worked absolutely fine on Windows, Linux, and macOS, but recently has started failing on Windows only with the following:
ENOENT: no such file or directory, realpath 'D:\a\enso-staging\enso-staging\repo\built-distribution\enso-engine-0.2.19-SNAPSHOT.2021-08-03-windows-amd64\enso-0.2.19-SNAPSHOT.2021-08-03\lib\Standard\Table\0.1.0\polyglot\java\xmlbeans-5.0.1\org\apache\xmlbeans\metadata\attribute\http_3A_2F_2Fwww_2Ew3_2Eorg_2FXML_2F1998_2Fnamespace'
Curiously enough, it works during our release workflow, but not our nighttly workflow, and we can't find any material difference between the two that would contribute to this.
Version
- V1
- V2
Environment
- self-hosted
- Linux
- Windows
- Mac
Run/Repo Url
You can find a failing run here.
How to reproduce
It fails consistently when running that workflow.
Activity
radeusgd commentedon Aug 9, 2021
A difference between the release workflow and the nightly workflow is that the version string (which is included twice in the mentioned path) is longer - release is something like
0.2.22and nightly is0.2.22-SNAPSHOT.2021-08-07. Since this only happens on Windows, it may be related to some issues with handling very long paths on Windows.radeusgd commentedon Aug 9, 2021
I have confirmed that the file for which ENOENT is raised does in fact exist, so it seems that somehow the error is caused by the long path.
After some digging I have found that the offending call seems to be the promise returning
fs.promises.realpath(...)called fromglobber.glob.I was able to replicate this in Node REPL too, calling
fs.promises.realpath(longpath)yielded the same error. Interestingly, calling the 'classic' callback-based variantfs.realpathon the same path was returning the correct result, so this looks like it may be a bug in Node's filesystem library.To try to reproduce this you may create a directory hierarchy
D:\a\enso-staging\enso-staging\repo\built-distribution\enso-engine-0.2.19-SNAPSHOT.2021-08-03-windows-amd64\enso-0.2.19-SNAPSHOT.2021-08-03\lib\Standard\Table\0.1.0\polyglot\java\xmlbeans-5.0.1\org\apache\xmlbeans\metadata\attribute\http_3A_2F_2Fwww_2Ew3_2Eorg_2FXML_2F1998_2Fnamespaceand try runningfs.promises.realpathon this path.radeusgd commentedon Aug 9, 2021
Reported this in the Node repo: nodejs/node#39721
Turn off log upload artifact in windows due to a bug
bazel-erlang becomes rules_erlang at version 2
bazel-erlang becomes rules_erlang at version 2
Turn off upload unpacked electron-builder files in windows due to a bug
laeubi commentedon Aug 3, 2022
We have a similar problem in the PDE project, is there any ETA for a fix, any information to provide or anything else to push this forward?
laeubi commentedon Aug 13, 2022
Is there any ETA when this get fixed? This currently makes the Windows artifacts upload unusable for us.
Disable artifact upload for windows due to actions/upload-artifact#240
Disable artifact upload for windows due to actions/upload-artifact#240
laeubi commentedon Nov 21, 2022
Still an issue :-(
Do not upload windows tests results
Do not upload windows tests results
HannesWell commentedon Dec 4, 2022
Is there any plan when this will be fixed?
kwin commentedon Dec 12, 2022
This should be fixed in the already released NodeJS 16.18.0 (nodejs/node@8d259e6086). Currently the Windows Runners come with NodeJS 16.18.1: https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md and https://github.com/actions/runner-images/blob/main/images/win/Windows2019-Readme.md. See also https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V16.md#16.18.0
kwin commentedon Dec 30, 2022
Although the upstream Node JS issue (nodejs/node#39721) is fixed with 16.8.0 we are still running into this issue (with a GH runner on Windows version: '2.299.1', using Node JS 16.8.1). Seems that there is some other issue with this action not related to the Node JS issue.
The failed run is at https://github.com/eclipse-m2e/m2e-core/actions/runs/3803309550/jobs/6469609937
CrazyHZM commentedon Jan 12, 2024
Is there any progress?
Handle nested zips as we will need to use them
Prezip reports to avoid Node.js and upload-artifact limitations
Piedone commentedon Feb 8, 2024
actions/checkout#955 would help here.
scrnjakovic commentedon May 23, 2024
Any progress with this?
btgoodwin commentedon Mar 5, 2025
Any progress on this? I'm not sure if this is the same problem I'm encountering or not because my path isn't nearly as long as the above example, but never-the-less, the artifact upload fails on the windows-latest runner with ENOENT for a path like this:
We have a preceding step also using this same action that only uploads the
C:\a\cerbero-action\cerbero-action\cerbero\cerbero-build\logs\*, but those paths would not be any longer than the above and that action succeeds.Disable artifact upload for windows due to actions/upload-artifact#240