aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/runtime/BuildEventStreamer.java
Commit message (Collapse)AuthorAge
* BuildEventStreamer: ingore noop-flush()sGravatar Klaus Aehlig2018-01-11
| | | | | | | | | | | | The BuildEventStreamer supports a method flush() to report any pending stdout/stderr in the BEP; in particular, all internal buffers of for those streams are cleared (and the memory can be reclaimed). If there are no pending bytes in those streams, however, there is no need to generate an additional progress event to get rid of the buffered stream contents. Make flush() a no-op in this case. Change-Id: Ia8cf8733fdeaf4d1a50488736d2637862e7cb4f5 PiperOrigin-RevId: 181590982
* Properly capitalize Build Event Protocol in Blaze output for consistency.Gravatar jingwen2017-12-14
| | | | | | | | | | | | | | | | | Before: ____Waiting for build event protocol upload: 0s ____Waiting for Build Event Protocol upload to finish. ____Build Event Protocol upload finished successfully. After: ____Waiting for Build Event Protocol upload: 0s ____Waiting for Build Event Protocol upload to finish. ____Build Event Protocol upload finished successfully. RELNOTES: None. PiperOrigin-RevId: 179049827
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own. This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually. PiperOrigin-RevId: 175033526
* BuildEventStreamer: allow final messagesGravatar aehlig2017-10-26
| | | | | | | | | | After receiving a BuildCompletingEvent, allow some final late messages, but only those not yet seen and announced by that BuildCompletingEvent. This mechanism will be used in a follow-up change to add a message with tool statistics. Change-Id: I979bec5bd946208068faff9a4ddd5245a769f096 PiperOrigin-RevId: 173514552
* BEP: correctly report unbuilt targets if --nobuild is givenGravatar Klaus Aehlig2017-10-25
| | | | | | | | | If bazel is asked to only analyze a target, but not do any builds, correctly report this as the cause why the obtained configured targets were never completed. Change-Id: I6308f8c222861dc0205a63664d5ea9861dd38b6a PiperOrigin-RevId: 173364084
* BEP: correctly report the cause of unbuilt targets if --noanalyze is givenGravatar Klaus Aehlig2017-10-20
| | | | | | | | | If bazel is asked to only load target, but not perform an analysis phase, correctly report this as the cause why the obtained targets wer never configured. Change-Id: Ib630a6dc1b955b810a6cc40254c0ae746e2eca1e PiperOrigin-RevId: 172787777
* BuildEventStreamer: clear a pending BuildStarted event firstGravatar Klaus Aehlig2017-10-16
| | | | | | | | | | | | | | | | | | | | If we receive an event indicating that the build is over, we first post that event and then clear up all pending event by stating that their prerequisite event was aborted (which we can safely assert, as we know we will not process any further events). Now, if a build is aborted (e.g., user interruption) before the build starting event is generated, the streamer can receive a build-finished event while still having an event (e.g., the raw command line) blocked on the build-starting event. So the canonical order of clearing the stream would send a build-finished event before the build-starting event, which can be confusing to consumers of the stream. Therefore, if have to generate an artificial aborted build-starting event, do so first (including clearing the events blocked on the build-starting event) and only afterwards post the build-finished event in the stream. Change-Id: Ib33f16f74b7bee7a963df94bbcad7a56db9f07e3 PiperOrigin-RevId: 172305114
* Unify buildevnts indicating build completionGravatar Klaus Aehlig2017-09-19
| | | | | | | ...by factoring out the common code parts. Change-Id: I2ead39ea218dd535af9684a81a7bbe29b558aa27 PiperOrigin-RevId: 169106854
* BEP: Upon missing test targets, still generate a finished eventGravatar Klaus Aehlig2017-09-15
| | | | | | | | If a test command is aborted as no tests are found, still generate a BuildComplete event in the sequence of build events to properly report the exit status. Change-Id: Id811a116b309a26e67332947b3a5c66363b1ce9c PiperOrigin-RevId: 168703240
* BEP: always close stream, even if aborted due to missing testsGravatar Klaus Aehlig2017-09-12
| | | | | | | | | | If testing is requested, but no tests are found, the build is aborted. Ensure that even in this case the steam of build events is internally closed (i.e., all announced events are reported, the last event is marked as such). Change-Id: I88763ed6ccd7793deedbcb3428df7e8d289efa23 PiperOrigin-RevId: 168364127
* Rename all logger instances to "logger" (instead "LOG" or "log").Gravatar lberki2017-09-05
| | | | | RELNOTES: None. PiperOrigin-RevId: 167505493
* Move extra action stuff to analysis.extraGravatar ulfjack2017-08-10
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164835678
* BEP: do not generate test summaries for broken testsGravatar Klaus Aehlig2017-08-02
| | | | | | | | | 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
* BuildEventWithConfiguration: represent configurations as BuildEventGravatar Klaus Aehlig2017-07-11
| | | | | | | | | | | 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
* BEP: Positively identify the last messageGravatar Klaus Aehlig2017-07-10
| | | | | | | | | | | 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
* Automated conversion to Java 8Gravatar laurentlb2017-06-30
| | | | | | | With a few manual fixes for readability. RELNOTES: None. PiperOrigin-RevId: 160582556
* BEP: Gracefully handle null configurationsGravatar Klaus Aehlig2017-06-28
| | | | | | | Those may occur, e.g., if the target is simply a source file. Change-Id: Ia64c54e8543dd93712b00428c443922c67e2b6cd PiperOrigin-RevId: 160278149
* Make BuildEventStreamer flushable before first eventGravatar Klaus Aehlig2017-06-26
| | | | | | | | | | | | | | | 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
* BEP: Support longer streams on non building commandsGravatar Klaus Aehlig2017-06-26
| | | | | | | | | | | | | 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
* Make NoBuildEvent an instance of BuildEventGravatar Klaus Aehlig2017-06-19
| | | | | | | | | | | 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
* BES: Consolidate BuildEventServiceModule and BuildEventStreamerModule.Gravatar buchgr2017-06-14
| | | | | | | | | | | | | | 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
* BEP: Correctly report test exit code.Gravatar buchgr2017-05-30
| | | | | | | | | | | | | 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
* BES: Capture stdout/stderr.Gravatar buchgr2017-05-30
| | | | | | | | 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
* BEP: send stdout/stderr in smaller chunksGravatar Klaus Aehlig2017-05-11
| | | | | | | | | | | 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
* BEP: Provide infrastructure to report configurationsGravatar Klaus Aehlig2017-05-08
| | | | | | | | | | 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
* BEP: Add WorkspaceStatusGravatar Klaus Aehlig2017-05-03
| | | | | | | | Add an event reporting the workspace status as key-value pairs reported via the workspace_status_command. Change-Id: I5791551798a594bc2465f483eb97f9d4fd4c7cfd PiperOrigin-RevId: 154845224
* BuildEventStreamer: support also providing stdout/stderrGravatar Klaus Aehlig2017-05-02
| | | | | | | | | | | | | 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
* Automated g4 rollback of commit d9fea57268ff01c001fbcbdc2bd057c86c362e6f.Gravatar buchgr2017-04-25
| | | | | | | | | | | | | | | | | | | | *** 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
* Automated g4 rollback of commit 3d596d63f883fff56001ed7b2e5cf51dba45f082.Gravatar ajmichael2017-04-25
| | | | | | | | *** Reason for rollback *** Made BuildEventStreamerTest#testSimpleStream 3% flaky based on --runs_per_test=1000. RELNOTES: None PiperOrigin-RevId: 154090559
* BEP: Show protocol upload in the UIGravatar buchgr2017-04-24
| | | | | | | | | | | | | | | | | | | | | | 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
* BEP: Extend infrastructure to allow reporting artifacts only onceGravatar Klaus Aehlig2017-04-07
| | | | | | | | | | 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
* BEP: Improve the BuildEventTransport interface.Gravatar buchgr2017-04-07
| | | | | | | | | | | | | | | | 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
* BEP: Unconditionally report ExtraActions Gravatar Klaus Aehlig2017-03-28
| | | | | | | | | | | | ...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
* BuildEventStreamer: fix handling of postedEvents Gravatar Klaus Aehlig2017-03-21
| | | | | | | | | | | | | 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
* BEP: Add BuildFinished event. Gravatar Jakob Buchgraber2017-02-28
| | | | | | | | | | | | 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
* Support ordering constraints on build eventsGravatar Klaus Aehlig2016-11-21
| | | | | | | | | | | | | | 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
* Writes a machine readable representation of BuildEvents to a file (varint ↵Gravatar Eduardo Colaco2016-11-03
| | | | | | | | | | | | | | | | | | | 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 completion of a target together with failed actionsGravatar Klaus Aehlig2016-10-27
| | | | | | | | | | | | | | | | 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
* Add a build-event streamer classGravatar Klaus Aehlig2016-10-04
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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 23:37:48 +0000