Runfiles tree creation fails on Windows #16955
Comments
ozio85
changed the title
|
Hello @ozio85, Could you please give complete steps to reproduce the above issue. Thanks! |
|
@bazel-io flag |
bazel-io
added
the
potential release blocker
|
Ok so now I have made a small repro. The bug manifests with remote_cache enable AND remote_download_toplevel set |
sgowroji
added
untriaged
team-Remote-Exec
|
So to repro this bug, you need to fill in a valid remote cache in .bazelrc: The build works fine with a local build. |
|
Note that you have to do a clean build in order to retrigger the runfiles tree build action, and this action has to be run in combination with the remote cache |
|
/cc @coeuvre |
|
I cannot reproduce this on macOS. It seems that the issue only occurs on Windows (because IIRC, MANIFEST based solution is only used for Windows). I will setup a Windows machine tomorrow to investigate more. |
|
@bazel-io fork 6.0.0 |
bazel-io
removed
the
potential release blocker
`getLastModifiedTime` and `setLastModifiedTime` are used by `FileSystemUtils.copyFile` to copy files. When runfiles is disabled, `SymlinkTreeStrategy#createSymlinks` use it to copy MANIFEST file. Fixes #16955. Closes #16972. PiperOrigin-RevId: 494712456 Change-Id: I9a77063f35e1f6e2559c02612790542e996994b8
…16993) `getLastModifiedTime` and `setLastModifiedTime` are used by `FileSystemUtils.copyFile` to copy files. When runfiles is disabled, `SymlinkTreeStrategy#createSymlinks` use it to copy MANIFEST file. Fixes #16955. Closes #16972. PiperOrigin-RevId: 494712456 Change-Id: I9a77063f35e1f6e2559c02612790542e996994b8 Co-authored-by: Chi Wang <[email protected]>
Description of the bug:
The runfiles tree creation currently fails on Windows.
The error is:
ERROR: ../BUILD.bazel:1:10: Creating runfiles tree bazel-out/x64_windows-fastbuild/bin/....exe.runfiles failed: java.io.FileNotFoundException: .../MANIFEST (No such file or directory), However the MANIFEST file is created and exists after the action crashes.
It started in release 6.0.0-pre.20221020.1, and a git bisect shows that #16477 is the culprit.
I will analyze the commit tomorrow, and see what might be the cause
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Create an actions.run that use a py_binary tool
Which operating system are you running Bazel on?
Windows
What is the output of
bazel info release?6.0.0-pre.20221020.1
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD?No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: