Get desktop application:
View/edit binary Protocol Buffers messages
Payload of an event indicating that an expected event will not come, as the build is aborted prematurely for some reason.
Used in:
A human readable description with more details about there reason, where available and useful.
Used in:
The user requested the build to be aborted (e.g., by hitting Ctl-C).
The user requested that no analysis be performed.
The user requested that no build be carried out.
The build or target was aborted as a timeout was exceeded.
The build or target was aborted as some remote environment (e.g., for remote execution of actions) was not available in the expected way.
Failure due to reasons entirely internal to the build tool, e.g., running out of memory.
A Failure occurred in the loading phase of a target.
A Failure occurred in the analysis phase of a target.
Target build was skipped (e.g. due to incompatible CPU constraints).
Payload of the event indicating the completion of an action. The main purpose of posting those events is to provide details on the root cause for a target failing; however, consumers of the build-event protocol must not assume that only failed actions are posted.
Used in:
The mnemonic of the action that was executed
The exit code of the action, if it is available.
Location where to find the standard output of the action (e.g., a file path).
Location where to find the standard error of the action (e.g., a file path).
Deprecated. This field is now present on ActionCompletedId.
Deprecated. This field is now present on ActionCompletedId.
Primary output; only provided for successful actions.
The command-line of the action, if the action is a command.
Message describing a build event. Events will have an identifier that is unique within a given build invocation; they also announce follow-up events as children. More details, which are specific to the kind of event that is observed, is provided in the payload. More options for the payload might be added in the future.
Identifier for a build event. It is deliberately structured to also provide information about which build target etc the event is related to. Events are chained via the event id as follows: each event has an id and a set of ids of children events such that apart from the initial event each event has an id that is mentioned as child id in an earlier event and a build invocation is complete if and only if all direct and indirect children of the initial event have been posted.
Used in:
Identifier of an event reporting that an action was completed (not all actions are reported, only the ones that can be considered important; this includes all failed actions).
Used in:
Optional, the label of the owner of the action, for reference.
Optional, the id of the configuration of the action owner.
Identifier of the BuildFinished event, indicating the end of a build.
Used in:
(message has no fields)
Identifier of an event providing build metrics after completion of the build.
Used in:
(message has no fields)
Identifier of an event indicating the beginning of a build; this will normally be the first event.
Used in:
(message has no fields)
Identifier of an event providing additional logs/statistics after completion of the build.
Used in:
(message has no fields)
Identifier of an event introducing a configuration.
Used in:
, , , , , ,Identifier of the configuration; users of the protocol should not make any assumptions about it having any structure, or equality of the identifier between different streams.
Identifier of an event reporting an event associated with a configured label, usually a visibility error. In any case, an event with such an id will always report some form of error (i.e., the payload will be an Aborted event); there are no regular events using this identifier.
Used in:
Identifier of an event reporting that an external resource was fetched from.
Used in:
The external resource that was fetched from.
Identifier of an event introducing a named set of files (usually artifacts) to be referred to in later messages.
Used in:
, ,Identifier of the file set; this is an opaque string valid only for the particular instance of the event stream.
Identifier on an event reporting on the options included in the command line, both explicitly and implicitly.
Used in:
(message has no fields)
Identifier of an event indicating that a target pattern has been expanded further. Messages of this shape are also used to describe parts of a pattern that have been skipped for some reason, if the actual expansion was still carried out (e.g., if keep_going is set). In this case, the pattern_skipped choice in the id field is to be made.
Used in:
Identifier of an event reporting progress. Those events are also used to chain in events that come early.
Used in:
Unique identifier. No assumption should be made about how the ids are assigned; the only meaningful operation on this field is test for equality.
Identifier on an event describing the commandline received by Bazel.
Used in:
A title for this command line value, as there may be multiple. For example, a single invocation may wish to report both the literal and canonical command lines, and this label would be used to differentiate between both versions.
Identifier of an event indicating that a target was built completely; this does not include running the test if the target is a test target.
Used in:
The configuration for which the target was built.
If not empty, the id refers to the completion of the target for a given aspect.
Identifier of an event indicating that a target has been expanded by identifying for which configurations it should be build.
Used in:
If not empty, the id refers to the expansion of the target for a given aspect.
Identifier of an event reporting on an individual test run. The label identifies the test that is reported about, the remaining fields are in such a way as to uniquely identify the action within a build. In fact, attempts for the same test, run, shard triple are counted sequentially, starting with 1.
Used in:
Identifier of an event reporting the summary of a test.
Used in:
Identifier of an event reporting an event associated with an unconfigured label. Usually, this indicates a failure due to a missing input file. In any case, it will report some form of error (i.e., the payload will be an Aborted event); there are no regular events using this identifier. The purpose of those events is to serve as the root cause of a failed target.
Used in:
Generic identifier for a build event. This is the default type of BuildEventId, but should not be used outside testing; nevertheless, tools should handle build events with this kind of id gracefully.
Used in:
Identifier on an event indicating the original commandline received by the bazel server.
Used in:
(message has no fields)
Identifier of an event indicating the workspace status.
Used in:
(message has no fields)
Event indicating the end of a build.
Used in:
If the build succeeded or failed.
The overall status of the build. A build was successful iff ExitCode.code equals 0.
Time in milliseconds since the epoch. TODO(buchgr): Use google.protobuf.Timestamp once bazel's protoc supports it.
Exit code of a build. The possible values correspond to the predefined codes in bazel's lib.ExitCode class, as well as any custom exit code a module might define. The predefined exit codes are subject to change (but rarely do) and are not part of the public API. A build was successful iff ExitCode.code equals 0.
Used in:
The name of the exit code.
The exit code.
Used in:
Used in:
The total number of actions created and registered during the build. This includes unused actions that were constructed but not executed during this build.
The total number of actions executed during the build. This includes any remote cache hits, but excludes local action cache hits.
Used in:
Size of the JVM heap post build in bytes. This is only collected if --bep_publish_used_heap_size_post_build is set, since it forces a full GC.
Used in:
Number of BUILD files (aka packages) loaded during this build.
Used in:
Number of targets loaded during this build.
Number of targets configured during this build. This can be greater than targets_loaded if the same target is configured multiple times.
Payload of an event indicating the beginning of a new build. Usually, events of those type start a new build-event stream. The target pattern requested to be build is contained in one of the announced child events; it is an invariant that precisely one of the announced child events has a non-empty target pattern.
Used in:
Start of the build in ms since the epoch. TODO(buchgr): Use google.protobuf.TimeStamp once bazel's protoc supports it.
Version of the build tool that is running.
A human-readable description of all the non-default option settings
The name of the command that the user invoked.
The working directory from which the build tool was invoked.
The directory of the workspace.
The process ID of the Bazel server.
Event providing additional statistics/logs after completion of the build.
Used in:
Payload of an event reporting details of a given configuration.
Used in:
Payload of an event indicating that an external resource was fetched. This event will only occur in streams where an actual fetch happened, not in ones where a cached copy of the entity to be fetched was used.
Used in:
Used in:
, , , , ,identifier indicating the nature of the file (e.g., "stdout", "stderr")
A location where the contents of the file can be found. The string is encoded according to RFC2396.
The contents of the file, if they are guaranteed to be short.
Payload of a message to describe a set of files, usually build artifacts, to be referred to later by their name. In this way, files that occur identically as outputs of several targets have to be named only once.
Used in:
Files that belong to this named set of files.
Other named sets whose members also belong to this set.
Payload of an event reporting on the parsed options, grouped in various ways.
Used in:
Collection of all output files belonging to that output group.
Used in:
Name of the output group
List of file sets that belong to this output group as well.
Payload of the event indicating the expansion of a target pattern. The main information is in the chaining part: the id will contain the target pattern that was expanded and the children id will contain the target or target pattern it was expanded to.
Used in:
(message has no fields)
Payload of an event summarizing the progress of the build so far. Those events are also used to be parents of events where the more logical parent event cannot be posted yet as the needed information is not yet complete.
Used in:
The next chunk of stdout that bazel produced since the last progress event or the beginning of the build.
The next chunk of stderr that bazel produced since the last progress event or the beginning of the build.
Payload of the event indicating the completion of a target. The target is specified in the id. If the target failed the root causes are provided as children events.
Used in:
The kind of target (e.g., e.g. "cc_library rule", "source file", "generated file") where the completion is reported. Deprecated: use the target_kind field in TargetConfigured instead.
The size of the test, if the target is a test target. Unset otherwise. Deprecated: use the test_size field in TargetConfigured instead.
The output files are arranged by their output group. If an output file is part of multiple output groups, it appears once in each output group.
Temporarily, also report the important outputs directly. This is only to allow existing clients help transition to the deduplicated representation; new clients should not use it.
List of tags associated with this configured target.
The timeout specified for test actions under this configured target.
Payload of the event indicating that the configurations for a target have been identified. As with pattern expansion the main information is in the chaining part: the id will contain the target that was configured and the children id will contain the configured targets it was configured to.
Used in:
The kind of target (e.g., e.g. "cc_library rule", "source file", "generated file") where the completion is reported.
The size of the test, if the target is a test target. Unset otherwise.
List of all tags associated with this target (for all possible configurations).
Payload on events reporting about individual test action.
Used in:
The status of this test.
Additional details about the status of the test. This is intended for user display and must not be parsed.
True, if the reported attempt is taken from the tool's local cache.
Time in milliseconds since the epoch at which the test attempt was started. Note: for cached test results, this is time can be before the start of the build.
Time the test took to run. For locally cached results, this is the time the cached invocation took when it was invoked.
Files (logs, test.xml, undeclared outputs, etc) generated by that test action.
Warnings generated by that test action.
Message providing optional meta data on the execution of the test action, if available.
Used in:
Deprecated, use TargetComplete.test_timeout_seconds instead.
Name of the strategy to execute this test action (e.g., "local", "remote")
True, if the reported attempt was a cache hit in a remote cache.
The exit code of the test action.
The hostname of the machine where the test action was executed (in case of remote execution), if known.
Used in:
Represents a hierarchical timing breakdown of an activity. The top level time should be the total time of the activity. Invariant: time_millis >= sum of time_millis of all direct children.
Used in:
Enumeration type characterizing the size of a test, as specified by the test rule.
Used in:
,Used in:
,Payload of the event summarizing a test. TODO(aehlig): extend event with additional information as soon as we known which additional information we need for test summaries.
Used in:
Wrapper around BlazeTestStatus to support importing that enum to proto3. Overall status of test, accumulated over all runs, shards, and attempts.
Total number of runs
Path to logs of passed runs.
Path to logs of failed runs;
Total number of cached test actions
Payload of an event reporting the command-line of the invocation as originally received by the server. Note that this is not the command-line given by the user, as the client adds information about the invocation, like name and relevant entries of rc-files and client environment variables. However, it does contain enough information to reproduce the build invocation.
Used in:
Payload of an event reporting the workspace status. Key-value pairs can be provided by specifying the workspace_status_command to an executable that returns one key-value pair per line of output (key and value separated by a space).
Used in:
Used in: