Breakage with Bazel HEAD due to 00805727b867d33fd922e63ca82b0d9825ad79fe #2464
Labels
cleanup
Tech debt, resolving it improves our own velocity
Comments
|
/cc @philwo @gyias @c-parsons |
|
Is it possibly related to our use of --nolegacy_external_runfiles? https://github.com/bazelbuild/rules_nodejs/blob/stable/common.bazelrc#L60-L62 |
|
Probably not. The triggering change is part of a project to deprecate the legacy external runfiles path. |
|
Hmm, I now think the commit isn't actually the culprit. I ran a CI with a revert, and it's still broken. |
|
Okay let us know if you need something from rules_nodejs maintainers...
…On Wed, Feb 17, 2021 at 1:00 PM Jaewoong Jung ***@***.***> wrote:
Hmm, I now think the commit isn't actually the culprit. I ran a CI with a
revert, and it's still broken
<https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1919#c241c4a5-0a18-4836-bdbf-a212d27b698e>
.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#2464 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALSIZUHKSCQRQPJVEHBTTS7QU6BANCNFSM4XWJY7SQ>
.
|
|
I believe the true culprit is bazelbuild/bazel@7149f57 FYI @lberki |
|
And this can only be reproduced with remote caching (or just --disk_cache=/tmp/bazel_disk_cache). I'm suspecting this is a bug in Bazel. |
bazel-io
pushed a commit
to bazelbuild/bazel
that referenced
this issue
Feb 19, 2021
Fixes a bunch of downstream breakages: bazelbuild/continuous-integration#1093 bazelbuild/continuous-integration#1094 bazel-contrib/rules_nodejs#2464 bazelbuild/rules_python#419 Turns out, the assertion that "Merkle tree computation uses `ActionInput.getExecPath()`" was only mostly correct: there was a place where the key of the input map was used instead. I'm somewhat surprised that this did not show up in our test battery, although, admittedly, "unsound directory as an input file in an external repository" doesn't sound like the most common use case. RELNOTES: None. PiperOrigin-RevId: 358366246
|
Confirming it is fixed: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1924 |
coeuvre
pushed a commit
to coeuvre/bazel
that referenced
this issue
Jul 15, 2021
… . Fixes a bunch of downstream breakages: bazelbuild/continuous-integration#1093 bazelbuild/continuous-integration#1094 bazel-contrib/rules_nodejs#2464 bazelbuild/rules_python#419 Turns out, the assertion that "Merkle tree computation uses `ActionInput.getExecPath()`" was only mostly correct: there was a place where the key of the input map was used instead. I'm somewhat surprised that this did not show up in our test battery, although, admittedly, "unsound directory as an input file in an external repository" doesn't sound like the most common use case. RELNOTES: None. PiperOrigin-RevId: 358366246
coeuvre
pushed a commit
to coeuvre/bazel
that referenced
this issue
Jul 15, 2021
… . Fixes a bunch of downstream breakages: bazelbuild/continuous-integration#1093 bazelbuild/continuous-integration#1094 bazel-contrib/rules_nodejs#2464 bazelbuild/rules_python#419 Turns out, the assertion that "Merkle tree computation uses `ActionInput.getExecPath()`" was only mostly correct: there was a place where the key of the input map was used instead. I'm somewhat surprised that this did not show up in our test battery, although, admittedly, "unsound directory as an input file in an external repository" doesn't sound like the most common use case. RELNOTES: None. PiperOrigin-RevId: 358366246
coeuvre
pushed a commit
to coeuvre/bazel
that referenced
this issue
Jul 16, 2021
… . Fixes a bunch of downstream breakages: bazelbuild/continuous-integration#1093 bazelbuild/continuous-integration#1094 bazel-contrib/rules_nodejs#2464 bazelbuild/rules_python#419 Turns out, the assertion that "Merkle tree computation uses `ActionInput.getExecPath()`" was only mostly correct: there was a place where the key of the input map was used instead. I'm somewhat surprised that this did not show up in our test battery, although, admittedly, "unsound directory as an input file in an external repository" doesn't sound like the most common use case. RELNOTES: None. PiperOrigin-RevId: 358366246
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This breakage was reported by our continuous integration.
https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1906#44b4eb78-3a05-4ecf-abdb-dfa16b20ff86
It is probably caused by bazelbuild/bazel@0080572 that calls test binaries in external repositories not using their legacy
external/$REPO/$REPO_RELATIVE_PATHpath but the canonical../$REPO/$REPO_RELATIVE_PATHone.I haven't looked into what the mechanism of the breakage is; my guess is that test binaries try to find data files relative to $0 and that logic needs to be updated.
This bug is also available in our continuous integration repository as bazelbuild/continuous-integration#1093 .
The text was updated successfully, but these errors were encountered: