| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules.
PiperOrigin-RevId: 164835678
|
|
|
|
|
|
|
|
|
| |
If a test fails to build, we obviously cannot run it.
Therefore, it does not make sense to have a summary of
the individual test runs.
Change-Id: I0445e7a58fc5c1f4feaa592a13da1c7f9c9be083
PiperOrigin-RevId: 163866309
|
|
|
|
|
|
|
|
|
|
|
| |
From a BEP point of view, the only interface of a configuration we care
about is its BuildEvent structure. Represent it as such, so that we
can move this class to the rest of the buildeventstream module. This
is a prerequisite for ActionOwners refering to configurations in the
BEP.
Change-Id: I6d1c1bf2951aac91607e83cad664553cd6620df8
PiperOrigin-RevId: 161510049
|
|
|
|
|
|
|
|
|
|
|
| |
Set an additional flag in the last BEP message to indicate the end
of the proto sequence. While the last event is implicit from the
child-relation (the sequence of protos is finished, if at least one
event is seen and all announced events have occurred in the stream),
an explicit marking of the last event simplifies processing.
Change-Id: I6554476f975dc9e52fdb27fb3221bd27f6097ed9
PiperOrigin-RevId: 161377092
|
|
|
|
|
|
|
| |
With a few manual fixes for readability.
RELNOTES: None.
PiperOrigin-RevId: 160582556
|
|
|
|
|
|
|
| |
Those may occur, e.g., if the target is simply a source file.
Change-Id: Ia64c54e8543dd93712b00428c443922c67e2b6cd
PiperOrigin-RevId: 160278149
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the BuildEventStreamer capable of handling the flush() method, even
before the initial build event is seen. This happens, if a lot (more than
10240 bytes) of output is produced before the BuildStartingEvent is generated-
This is not unlikely, as the whole option processing happens before the build
starts.
As the promise of flush() is that the OutErrProvider is cleared, and that all
output between two flush() get into separate events, numbered in order, we have
to temporarily store a list of stdout/stderr String pairs.
RELNOTES: None.
PiperOrigin-RevId: 160137478
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the build event protocol is mainly targeted for commands that actually
build, a minimal stream is generated for all commands. For commands like "query",
it is desirable that the stream contains the full output of the command.
To achieve this, introduce an optional second event indicating the end of the stream;
note that the NoBuildEvent has to come before the payload answer as the
experimental UI uses this event to determine the transition to the payload answer
that is passed through unchanged.
RELNOTES: None.
PiperOrigin-RevId: 159977543
|
|
|
|
|
|
|
|
|
|
|
| |
Not all bazel invocations produce a BuildStartingEvent; in fact, not all
commands include building. Those invocations produce a NoBuildEvent instead.
However, some of those invocations, like "query", might still have important
machine-readable information to report, like errors in BUILD files. So, make
the NoBuildEvent a build event, capable of starting a stream of build events.
Change-Id: I7cab65f029cdc0176ea5c4970308de296fb73177
PiperOrigin-RevId: 159230205
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After having open sourced the Build Event Service code, there is no more need
to have two separate bazel modules that both create a BuildEventStreamer.
This change merges the BuildEventStreamerModule logic into the
BuildEventServiceModule.
DELTA=677 (330 added, 316 deleted, 31 changed)
DELTA_BY_EXTENSION=java=293,oss=32
RELNOTES: None.
PiperOrigin-RevId: 158960687
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a test failure occurred the BEP would still report a build_finished event
with exit code SUCCESS, even though bazel's exit code was TESTS_FAILED. This is
because we would rely on the exit code reported by the BuildCompleteEvent. However,
this exit code contains only the build status without taking into account the test status.
In this change we introduce the TestingCompleteEvent that reports bazel's final
exit code in case of "bazel test".
RELNOTES: None.
PiperOrigin-RevId: 157445808
|
|
|
|
|
|
|
|
| |
The BEP protocol currently does not include stdout/stderr when sent over BES.
This change makes the BuildEventStreamer created by the BuildEventServiceModule listen in on stdout/stderr.
RELNOTES: None.
PiperOrigin-RevId: 157439952
|
|
|
|
|
|
|
|
|
|
|
| |
While sending chunks of stdout/stderr when a progress event is sent anyway
is a good idea, we cannot entirely rely on this, as the amount of information
buffered might grow too big. So set a fixed limit after which we flush out
stdout and stderr; nevertheless, we still make sure we send buffers that were
given to us in a single call to write in one go.
Change-Id: Ie27bcf7d50671e003babd13cdb1d3f7fc1cb232f
PiperOrigin-RevId: 155736641
|
|
|
|
|
|
|
|
|
|
| |
In preparation to support multi-configuration builds, provide infrastructure
allowing build events to reference BuildConfigurations. The streaming mechanism
will ensure that build configurations are introduced in the stream before being
referenced for the first time.
Change-Id: I6b96fbebc76a05eff4f75a07e8a9cfbcd57f9c22
PiperOrigin-RevId: 155368666
|
|
|
|
|
|
|
|
| |
Add an event reporting the workspace status as key-value pairs reported
via the workspace_status_command.
Change-Id: I5791551798a594bc2465f483eb97f9d4fd4c7cfd
PiperOrigin-RevId: 154845224
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the build-event streamer to also report about stdout/stderr,
if provided. This information is reported in the progress events. At
the moment, we only report stdout/stderr in progress events we send
anyway, but the interface is generic enough that we could add time-based
reporting later, if needed. Also note, that at the end of the build, we
report the final progress event, so that all stdout/stderr generated before
the build-complete event get also reported in the build-event protocol.
Change-Id: If5dbd59c151edbce02d0a9b2e5938b63c0a5dc58
PiperOrigin-RevId: 154811110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rollforward with fix for test flakiness. BEP transport closed
events are delivered via their own threadpool and thus might
not have been sent immediately. BuildEventStreamerTest#testSimpleStream
now waits for a bit until the event has been delivered. I ran the test
with --runs_per_test=1000 several times and had no further failures.
*** Original change description ***
Automated g4 rollback of commit 3d596d63f883fff56001ed7b2e5cf51dba45f082.
*** Reason for rollback ***
Made BuildEventStreamerTest#testSimpleStream 3% flaky based on --runs_per_test=1000.
RELNOTES: None
PiperOrigin-RevId: 154170833
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Made BuildEventStreamerTest#testSimpleStream 3% flaky based on --runs_per_test=1000.
RELNOTES: None
PiperOrigin-RevId: 154090559
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The BEP (build event protocol) upload may at times take longer than the build
itself. This is especially true for cached builds, where there is little build
work, but the protocol still needs to be uploaded. In this case the bazel UI
will now display that it's waiting for BEP upload, both in the current and the
new experimental UI (--experimental_ui).
When executing a run command, blaze waits for the BEP upload to finish before
it runs the target.
Major Modifications:
- The BuildEventTransport interface now also has a name() method that returns
a string. When waiting for a transport to finish the BEP upload, this string
is displayed in the UI.
- The BuildEventStreamer now emits two new events
AnnounceBuildEventTransportsEvent and BuildEventTransportClosed on the event
bus. This is how the experimental UI is informed about BEP upload progress.
RELNOTES: None
PiperOrigin-RevId: 154052401
|
|
|
|
|
|
|
|
|
|
| |
Extend the functionality of the BuildEventStreamer to report those parts
of NestedSets of Artifacts not reported earlier. In this way, duplicate
reporting can be avoided, without the events themselves having to know
which artifacts are known already.
Change-Id: Ia959c28c440301860eac57ea5d9a712c0d49ebdf
PiperOrigin-RevId: 152497672
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Better specify the BuildEventTransport interface. Besides clarifying threading
and blocking issues, this change also clarifies error handling/reporting.
After several discussions we concluded that the BuildEventTransport interface
should not provide error reporting / handling facilities, as there is not much
bazel could do with this information. Instead, a transport may decide for
itself if an error is fatal and abort the build or if an error should be logged
to the user's terminal or if it should be ignored.
Furthermore, changing the close() method lays the groundwork for an upcoming
change that will report the transport shutdown status to the user command
line.
PiperOrigin-RevId: 152408938
|
|
|
|
|
|
|
|
|
|
|
|
| |
...irrespective of their success status. While a build typically
contains too many successful actions to report them all, extra actions
included in a build are worth reporting.
--
Change-Id: I6b20935895aa7b16836d6271f456176a7113317e
Reviewed-on: https://cr.bazel.build/9519
PiperOrigin-RevId: 151328633
MOS_MIGRATED_REVID=151328633
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Always initialize the set of postedEvents. Also, record the initial event
as posted. In this way, the build event streamer can also handle events that
should be posted after the BuildStartedEvent but are told the streamer about
earlier.
--
Change-Id: Ic796f2434434819e6c62633755411527a9dcb7e0
Reviewed-on: https://cr.bazel.build/9451
PiperOrigin-RevId: 150620387
MOS_MIGRATED_REVID=150620387
|
|
|
|
|
|
|
|
|
|
|
|
| |
The build event protocol now emits a BuildFinished event at the end of a build. The event is a child of the BuildStarted event.
The code changes were larger than expected, due to some refactoring in BuildEventStreamer. This was necessary as the BuildCompleteEvent now implements the BuildEvent interface and Guava's EventBus always invokes the most specialized subscriber method. Thus, the buildEvent(BuildEvent) and buildCompleted(BuildCompletedEvent) methods had to be merged.
--
Change-Id: Id0c2bd7220dc8ce03128b7126587e212ee8ce836
Reviewed-on: https://cr.bazel.build/9053
PiperOrigin-RevId: 148788582
MOS_MIGRATED_REVID=148788582
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the build event protocol, we promise to respect certain ordering
constraints that come naturally by causality anyway (e.g., the root
cause of a failure has to come before the failure). However, in the
way the call structure is organized, events might occur on the event
bus in wrong order. So allow events to specify that order and make the
streamer honor it.
--
Change-Id: I1fbe9b93681f0ddfa35d9d00d5d1b02103da38a5
Reviewed-on: https://bazel-review.googlesource.com/#/c/7370
MOS_MIGRATED_REVID=139774946
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
delimited).
Adds --experimental_build_event_binary_file option that enables varint delimited proto loggging to the specified file path
Adds varint delimited BuildEventStreamTransport and BuildEventStreamerModule
Adds BuildEventStreamerModule for configuring and setting up BuildEventStreamer and its associated BuildEventTransports.
Adds BuildEventTransportFactory which creates a Set of transports from command options.
Moves BuildEventStreamer configuration from BlazeCommandDispatcher and BuildEventStreamerModule
--
Change-Id: If71f2b58654879c2509206da47e6d1a846bf397f
Reviewed-on: https://bazel-review.googlesource.com/#/c/7010/
MOS_MIGRATED_REVID=138073726
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Report the completion of all targets together with the root causes on the build
event stream. To do so, have TargetCompleteEvent and ActionExecutedEvent be
instances of BuildEvent; however, ignore an ActionExecutedEvent in the
BuildEventStreamer if the execution was successful.
By this change we get, for the first time, a build event stream that is naturally
closed, i.e., without Aborted events closing up lose ends. Add a test asserting
this property.
--
Change-Id: Ie90dd52ee80deb0fdabdce1da551935522880a1a
Reviewed-on: https://bazel-review.googlesource.com/#/c/6279
MOS_MIGRATED_REVID=137273002
|
|
The BuildEventStreamer will listen for BuildEvents and stream them
to the provided transports. It also ensures events are properly chained:
for unsolicited events, it will add progress events to chain them and
at the end of a build it closes all announced but not produced events
as aborted.
--
Change-Id: I623b582657573fe1288821c96f084e0ab0bca4d4
Reviewed-on: https://bazel-review.googlesource.com/#/c/6275
MOS_MIGRATED_REVID=134787541
|