Open mortenmj opened 2 months ago
cc @meteorcloudy
This is so weird, the way a repo is vendored is by moving its source from the external root to the vendor directory, we are not even copying any files around: https://github.com/bazelbuild/bazel/blob/5209ce7587d4f8da37d7492d91d0aac1b91ab249/src/main/java/com/google/devtools/build/lib/bazel/bzlmod/VendorManager.java#L94-L96
It'll be really helpful if you can somehow construct a potential reproducible case.
Description of the bug:
Occasionally, when vendoring all dependencies in our repository, file content can be written to the wrong file, leading to corrupt dependencies. Other than stress testing the system by vendoring a large number of dependencies, which is when I generally see this, I am not sure how to reproduce this reliably. In the specific example I'm seeing now, a partial golang source file has been written to a BUILD.bazel file.
Which category does this issue belong to?
Core
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Run
bazel vendor //...
in a repository with many external dependencies, potentially several times in order to trigger the issueWhich operating system are you running Bazel on?
Linux
What is the output of
bazel info release
?release 7.3.1
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD
?No response
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
Running in a GitHub Codespace. May or may not matter w.r.t. the reliability of the underlying platform