| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
This reduces the size of its serialized representation.
PiperOrigin-RevId: 188597127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...as completion of the respective top-level targets. In this way,
a failure is associated to its root cause, even if the cause is at
analysis phase; in particular, visibility errors are correctly
associated.
For the time beeing, we associate visibility root causes only with
labels; it is planned to change that to the more accurate configured
labels in a follow-up change.
Change-Id: I04121a7cd2099fc65171eae0719fd77b98aef09b
PiperOrigin-RevId: 183359798
|
|
|
|
|
|
|
|
|
|
| |
A build might fail because of a visibility violation that does
not happen at a top-level target. To avoid confusion, add a separate
namespace for configured targets that are just mentioned to report
the details of an error.
Change-Id: I86587f7489500f1d888bae6ce3d6f4bd79ea1609
PiperOrigin-RevId: 181448003
|
|
|
|
|
|
|
|
|
|
| |
After the completion of the build, also report useful logs/statistics.
Do so in a separate event, so that the protocol allows reporting build
completion early and purely staticial information later, maybe event after
some computations.
Change-Id: Ibd221546de76fcffcda7819c300187eac45ebd68
PiperOrigin-RevId: 173548733
|
|
|
|
|
|
|
|
|
| |
This is part of the effort outlined in https://bazel.build/designs/2017/07/13/improved-command-line-reporting.html. The refactoring of the options parser is not yet complete, so we still do not have complete & correct information about the canonical command line. Where the information is blatantly incorrect, a best approximation was made, with comments and tests documenting the deficiencies.
Change the names of the initial CommandLine fields in the BEP to be explicitly identified as unstructured.
RELNOTES: None.
PiperOrigin-RevId: 171625377
|
|
|
|
|
|
|
|
|
| |
Adding an event about which completed aspects to expect allows for earlier
feedback of what the aspect is doing. It also allows consumers of the build
event stream to prepare for the TargetCompleted events of the aspect.
Change-Id: I29ef15472867a7169222e0394c7fe061fd1d2994
PiperOrigin-RevId: 167248206
|
|
|
|
|
|
|
|
| |
This is a first step on moving the configuration checksum and target
label from the ActionExecuted payload and into ActionCompletedId.
Change-Id: I989c9b708cd2a4172f6483d97bc7842d9841e3a8
PiperOrigin-RevId: 163233097
|
|
|
|
|
|
|
|
|
| |
Fetching is an important action, if it happens, as external
resources are accessed. Therefore, report this activity in
the build event stream.
Change-Id: Ia443fe01e6478016993231377d8f65c5d4634e00
PiperOrigin-RevId: 163184329
|
|
|
|
|
|
|
| |
Those may occur, e.g., if the target is simply a source file.
Change-Id: Ia64c54e8543dd93712b00428c443922c67e2b6cd
PiperOrigin-RevId: 160278149
|
|
|
|
|
|
|
|
| |
In multi-configuration builds, test can be run for different configurations as well. So
we have to report the configuration for each test as well.
Change-Id: I939cce7464823fbcd3c7161a50b41b94bbed8812
PiperOrigin-RevId: 155493397
|
|
|
|
|
|
|
|
|
|
|
| |
In multi-architecture builds, a target might be built several times,
for the different architectures. Make the target completion events for
those distinguishable by indicating the architecture for which the target
was built. Also add the needed event for the expansion of a target to
target-configuration pairs.
Change-Id: I95ef2c81166077163dd686db4671f672160efe1d
PiperOrigin-RevId: 155491076
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
In this way, all indices are reported with 1 being the smallest
possible. Also, the numbers fit better with the file names generated
for log files etc.
Change-Id: I7671e5a79dd47c3e3afac16108acaeacdf018fc5
PiperOrigin-RevId: 153080339
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
...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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Additionally to reporting on the originally received command line, also report
it in a parsed form. This, in particular, includes reconstructing the options
originally provided by the user.
--
Change-Id: I5a1c6ed57874f1d37d10bf11d597256d63bc5516
Reviewed-on: https://cr.bazel.build/9459
PiperOrigin-RevId: 151288656
MOS_MIGRATED_REVID=151288656
|
|
|
|
|
|
|
|
|
|
|
|
| |
...so we can report it in the build event protocol no matter what
changes the various option parsers and modules do to the command
line.
--
Change-Id: I497d6dbbf1fc2849580271833797755cb0c9d13c
Reviewed-on: https://cr.bazel.build/9452
PiperOrigin-RevId: 150737198
MOS_MIGRATED_REVID=150737198
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this way, we can also report the artifacts generated
by aspects in the build event protocol.
For the time being, those events are reported unsolicitly
(i.e., as children of progress events), but they may be linked
to pattern expansion later.
--
Change-Id: I7fb83088d7fdb5424f77bfb78700e8371231b13c
Reviewed-on: https://cr.bazel.build/9370
PiperOrigin-RevId: 150181433
MOS_MIGRATED_REVID=150181433
|
|
|
|
|
|
|
|
|
|
|
| |
If expanding a pattern fails, report this on the build event protocol;
also include details of what happened.
--
Change-Id: I2bc9caf7c085911b80551d7892cc34f5e9961c7b
Reviewed-on: https://cr.bazel.build/8795
PiperOrigin-RevId: 148894326
MOS_MIGRATED_REVID=148894326
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
For tests known to be flaky, additional attempts are run. Also report
about those in the build-event protocol.
--
Change-Id: I287b0b78478949abe5e14a9fafb1fd463aba8287
Reviewed-on: https://cr.bazel.build/8570
PiperOrigin-RevId: 146454273
MOS_MIGRATED_REVID=146454273
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only having a test summary for each test target is not enough for timely
error reporting. Also individual test actions and attempts are of interest.
Report those by making TestResult an instance of BuildEvent.
--
Change-Id: Iee1c988b6d467ebda8230b9edacbe3b66600c30e
Reviewed-on: https://cr.bazel.build/8532
PiperOrigin-RevId: 146342845
MOS_MIGRATED_REVID=146342845
|
|
|
|
|
|
|
|
|
|
|
| |
For each test target, also have a test summary as children to this event.
As test summaries are posted on the event bus anyway, it is enough to
make then an instance of BuildEvent.
--
Change-Id: Id53e5f1760548a1fa621b1667fdb4470f51a52e8
Reviewed-on: https://bazel-review.googlesource.com/#/c/6931
MOS_MIGRATED_REVID=137961100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
...by making TargetParsingCompleteEvent an instance of BuildEvent. The main
value of this event on the event stream is that it is now know which actual
targets to expect.
--
Change-Id: I50b16f825d742d28e719692489de701d16195efa
Reviewed-on: https://bazel-review.googlesource.com/#/c/6278
MOS_MIGRATED_REVID=135661452
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the BuildStartingEvent visible in the event stream by making it
an instance of the BuildEvent interface. It is the initial event of the
build event stream hence it also announces that progress updates will
follow. Its regular decedents are the expansion of the target patterns
provided at the request.
--
Change-Id: I237d8559b71ac82b10fdc492492b8435d6d1483f
Reviewed-on: https://bazel-review.googlesource.com/#/c/6277
MOS_MIGRATED_REVID=135475422
|
|
Bazel in the will provide a machine-readable stream of important build
events. These interfaces set up the framework and expectations about
the produced events and the entities distributing those events.
--
Change-Id: If2c3b2e11c31b0136b57eadeef2d2f8f8fe5e2e7
Reviewed-on: https://bazel-review.googlesource.com/#/c/6272
MOS_MIGRATED_REVID=134522369
|