| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 154553183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|