| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
For requests like fetch, we still produce a sequence of build
events, even though nothing is actually built. In the BuildStarting
event of that stream, also report the UUID of the request.
Change-Id: If34ce6a34221320ed4a24408732ba6d372569d04
PiperOrigin-RevId: 164710704
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than assuming that all events are part of a build until
NoBuildEvent or BuildCompleteEvent are posted, only start reporting
build progress after a BuildStartingEvent or a NoBuildEvent with
showProgress() true happens.
This fixes https://github.com/bazelbuild/bazel/issues/3449.
Change-Id: I78372a2286a4595cf3301c998be2c9036ad0f4b7
PiperOrigin-RevId: 163447622
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For commands that do not send a BuildFinishedEvent, we normally use the
NoBuildEvent to determine the end of the build and hence the moment
where the UI should not any more interfere with the output. For some
requests, like fetch, however, we should continue to report progress
till the very end (as there is no output to interfere with). Do so,
and also be sure that the experimental UI also reports downloads if
not explicitly in a loading or analysis phase.
While there, also group digits in the number of downloaded bytes, to
increase readability.
Change-Id: I31efeee5bdb1d29b2ecf842acb3e383e297707f8
PiperOrigin-RevId: 161935456
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
In the experimental UI, during build, STDOUT and STDERR events
are reported as separate events, properly terminated by CR LF.
After the completion of the build, however, STDOUT and STDERR
are passed through byte by byte, to allow nicely formatted output.
Info commands, however, do not build, so there is no event to signal
end of build; hence report that fact directly to the UI.
--
Change-Id: Ic236d33ee6e65637016370e15ed37e3d9494a258
Reviewed-on: https://bazel-review.googlesource.com/#/c/3122
MOS_MIGRATED_REVID=117934742
|