Breakage with Bazel@HEAD #419
Comments
|
/cc @philwo @gyias @c-parsons |
|
FYI, I ran a downstream CI with bazelbuild/bazel@0080572 reverted, but they're still broken. |
|
Breakage is caused by bazelbuild/bazel@7149f57, sorry. |
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 |
|
Thanks @comius |
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
rules_pythonis broken on the continuous integration tests of Bazel @ HEAD:https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1905#e9759395-101f-4047-b7c9-daa0fc4eb714
This breakage 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
$0and that logic needs to be updatedThis issue is also available in our
continuous-integrationrepository as bazelbuild/continuous-integration#1094 .The text was updated successfully, but these errors were encountered: