Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

rules_nodejs broken on macos CI Bazel@HEAD #1093

Closed
c-parsons opened this issue Feb 10, 2021 · 5 comments
Closed

rules_nodejs broken on macos CI Bazel@HEAD #1093

c-parsons opened this issue Feb 10, 2021 · 5 comments

Comments

@c-parsons
Copy link
Contributor

c-parsons commented Feb 10, 2021 •
edited
Loading

https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1906#44b4eb78-3a05-4ecf-abdb-dfa16b20ff86

Broken only on Bazel@HEAD, only on macos, verified it's not a one-off flake.

Failure has no culprit, looks like it might be machine configuration?
Not sure how to diagnose.

Error snippet:

(17:28:01) ERROR: /Users/buildkite/builds/bk-imacpro-1/bazel-downstream-projects/rules_nodejs/packages/protractor/test/protractor-2/BUILD.bazel:76:26: Testing //packages/protractor/test/protractor-2:devserver_test_chromium-local failed: Exec failed due to IOException: /private/var/tmp/_bazel_buildkite/91c18959b05b90458bcda693ef4a8678/execroot/build_bazel_rules_nodejs/build_bazel_rules_nodejs/bazel-out/darwin-fastbuild/bin/packages/protractor/test/protractor-2/devserver_test_chromium-local.sh.runfiles/io_bazel_rules_webtesting/third_party/chromium/chromium.out/chrome-mac/Chromium.app/Contents/Frameworks/Chromium Framework.framework/Helpers (No such file or directory)
@c-parsons c-parsons changed the title rules_nodejs broken on CI Bazel@HEAD rules_nodejs broken on macos CI Bazel@HEAD Feb 10, 2021
@philwo
Copy link
Member

philwo commented Feb 16, 2021

Auto-Sheriff identified this commit as the culprit: bazelbuild/bazel@0080572

@meteorcloudy
Copy link
Member

/cc @lberki @comius

@lberki lberki mentioned this issue Feb 16, 2021
Closed
@comius
Copy link
Collaborator

comius commented Feb 16, 2021 •
edited
Loading

Actually Auto-Sheriff determined another culprit: bazelbuild/bazel@7149f57.
But this doesn't seem to affect reported issue on rules_nodejs.

bazel-io pushed a commit to bazelbuild/bazel that referenced this issue Feb 19, 2021
@lberki @copybara-github
Make the Merkle tree computation work in the wake of 7149f57 .
4efeac9 
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
@comius
Copy link
Collaborator

comius commented Feb 19, 2021

Confirming it's fixed https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1924

@meteorcloudy
Copy link
Member

@comius Thanks for confirming!

coeuvre pushed a commit to coeuvre/bazel that referenced this issue Jul 15, 2021
@lberki @coeuvre
Make the Merkle tree computation work in the wake of bazelbuild@7149f57…
b0d4bcc 
… .

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
@lberki @coeuvre
Make the Merkle tree computation work in the wake of bazelbuild@7149f57…
ff4c108 
… .

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
@lberki @coeuvre
Make the Merkle tree computation work in the wake of bazelbuild@7149f57…
c901827 
… .

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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@philwo @comius @meteorcloudy @c-parsons