-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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.
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
Build event streams generated by Bazel 6.3.0 and later no longer include the remote execution message in such a way that it's attached to the action that failed #19327
Comments
@EdSchouten Could you please provide output or logs when you execute? |
This is what I get in the console:
I can't share the full build event log, as it contains a lot of private data that I don't want to share (e.g., tokens). Here's the progress message that gets generated:
Notice that the URL is in there, but that it's not really possible to extract it in a meaningful/portable way. |
I can create a reproduction I get different results for local/remote with bazel 6.3.0 here, A recipe/automation script here: https://github.com/stagnation/bb-deployments/blob/feature/reproduce-bazel-issue-19327/19327.sh |
Since it makes it harder for BEP consumers to present the messages in a structured way. Fixes bazelbuild#19327. This reverts commit 6d089b3.
@bazel-io flag |
@bazel-io fork 6.4.0 |
Should be fixed by #19347. |
Since it makes it harder for BEP consumers to present the messages in a structured way. Fixes bazelbuild#19327. This reverts commit 6d089b3.
Since it makes it harder for BEP consumers to present the messages in a structured way. Fixes bazelbuild#19327. This reverts commit 6d089b3. Closes bazelbuild#19347. PiperOrigin-RevId: 562793125 Change-Id: I6ea41323c4ea98d416e4cfd9728d0d753aef9b5e
A fix for this issue has been included in Bazel 6.4.0 RC1. Please test out the release candidate and report any issues as soon as possible. Thanks! |
Description of the bug:
PR #18757 changed the way Bazel emits remote execution messages. They are now console events instead of being attached to stdout/stderr. This change on its own is all right, but it now means that if you look at the build event file they are only part of the "progress" messages. This is really annoying, as it means the messages don't show up anywhere near the place where the actual execution failure is described.
You could in theory extract the information from the progress message, but what's annoying about that is that you likely need to use some VT100 escape sequence parser to interpret that data in a meaningful way.
Furthermore, the event that is printed to the console is incomplete. Sure, it contains the target name, but it does not have the configuration ID either. This means that if the same target is built multiple times (e.g., once for the host, once for the target), it's not possible to figure out which it belongs to.
Which category does this issue belong to?
Remote Execution
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Build this target against a remote execution system that generates execution messages:
Then run
bazel build --build_event_json_file=${HOME}/x ...
Which operating system are you running Bazel on?
Any
What is the output of
bazel info release
?6.3.0
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 master; git rev-parse HEAD
?No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
#18757
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: