Namespace Google.Apis.RemoteBuildExecution.v2.Data
Classes
BuildBazelRemoteExecutionV2Action
An Action
captures all the information about an execution which is required to reproduce it. Action
s are the
core component of the [Execution] service. A single Action
represents a repeatable action that can be
performed by the execution service. Action
s can be succinctly identified by the digest of their wire format
encoding and, once an Action
has been executed, will be cached in the action cache. Future requests can then
use the cached result rather than needing to run afresh. When a server completes execution of an Action, it MAY
choose to cache the result in the ActionCache unless do_not_cache
is true
. Clients SHOULD expect the server
to do so. By default, future calls to Execute the same Action
will also serve their results from the cache.
Clients must take care to understand the caching behaviour. Ideally, all Action
s will be reproducible so that
serving a result from cache is always desirable and correct.
BuildBazelRemoteExecutionV2ActionCacheUpdateCapabilities
Describes the server/instance capabilities for updating the action cache.
BuildBazelRemoteExecutionV2ActionResult
An ActionResult represents the result of an Action being run. It is advised that at least one field (for example
ActionResult.execution_metadata.Worker
) have a non-default value, to ensure that the serialized value is
non-empty, which can then be used as a basic data sanity check.
BuildBazelRemoteExecutionV2BatchReadBlobsRequest
A request message for ContentAddressableStorage.BatchReadBlobs.
BuildBazelRemoteExecutionV2BatchReadBlobsResponse
A response message for ContentAddressableStorage.BatchReadBlobs.
BuildBazelRemoteExecutionV2BatchReadBlobsResponseResponse
A response corresponding to a single blob that the client tried to download.
BuildBazelRemoteExecutionV2BatchUpdateBlobsRequest
A request message for ContentAddressableStorage.BatchUpdateBlobs.
BuildBazelRemoteExecutionV2BatchUpdateBlobsRequestRequest
A request corresponding to a single blob that the client wants to upload.
BuildBazelRemoteExecutionV2BatchUpdateBlobsResponse
A response message for ContentAddressableStorage.BatchUpdateBlobs.
BuildBazelRemoteExecutionV2BatchUpdateBlobsResponseResponse
A response corresponding to a single blob that the client tried to upload.
BuildBazelRemoteExecutionV2CacheCapabilities
Capabilities of the remote cache system.
BuildBazelRemoteExecutionV2Command
A Command
is the actual command executed by a worker running an Action and specifications of its environment.
Except as otherwise required, the environment (such as which system libraries or binaries are available, and
what filesystems are mounted where) is defined by and specific to the implementation of the remote execution
API.
BuildBazelRemoteExecutionV2CommandEnvironmentVariable
An EnvironmentVariable
is one variable to set in the running program's environment.
BuildBazelRemoteExecutionV2Digest
A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to
use is defined by the server. The size is considered to be an integral part of the digest and cannot be
separated. That is, even if the hash
field is correctly specified but size_bytes
is not, the server MUST
reject the request. The reason for including the size in the digest is as follows: in a great many cases, the
server needs to know the size of the blob it is about to work with prior to starting an operation with it, such
as flattening Merkle tree structures or streaming it to a worker. Technically, the server could implement a
separate metadata store, but this results in a significantly more complicated implementation as opposed to
having the client specify the size up-front (or storing the size along with the digest in every message where
digests are embedded). This does mean that the API leaks some implementation details of (what we consider to be)
a reasonable server implementation, but we consider this to be a worthwhile tradeoff. When a Digest
is used to
refer to a proto message, it always refers to the message in binary encoded form. To ensure consistent hashing,
clients and servers MUST ensure that they serialize messages according to the following rules, even if there are
alternate valid encodings for the same message: * Fields are serialized in tag order. * There are no unknown
fields. * There are no duplicate fields. * Fields are serialized according to the default semantics for their
type. Most protocol buffer implementations will always follow these rules when serializing, but care should be
taken to avoid shortcuts. For instance, concatenating two messages to merge them may produce duplicate fields.
BuildBazelRemoteExecutionV2Directory
A Directory
represents a directory node in a file tree, containing zero or more children FileNodes,
DirectoryNodes and SymlinkNodes. Each Node
contains its name in the directory, either the digest of its
content (either a file blob or a Directory
proto) or a symlink target, as well as possibly some metadata about
the file or directory. In order to ensure that two equivalent directory trees hash to the same value, the
following restrictions MUST be obeyed when constructing a a Directory
: * Every child in the directory must
have a path of exactly one segment. Multiple levels of directory hierarchy may not be collapsed. * Each child in
the directory must have a unique path segment (file name). Note that while the API itself is case-sensitive, the
environment where the Action is executed may or may not be case-sensitive. That is, it is legal to call the API
with a Directory that has both "Foo" and "foo" as children, but the Action may be rejected by the remote system
upon execution. * The files, directories and symlinks in the directory must each be sorted in lexicographical
order by path. The path strings must be sorted by code point, equivalently, by UTF-8 bytes. * The NodeProperties
of files, directories, and symlinks must be sorted in lexicographical order by property name. A Directory
that
obeys the restrictions is said to be in canonical form. As an example, the following could be used for a file
named bar
and a directory named foo
with an executable file named baz
(hashes shortened for readability):
json // (Directory proto) { files: [ { name: "bar", digest: { hash: "4a73bc9d03...", size: 65534 },
node_properties: [ { "name": "MTime", "value": "2017-01-15T01:30:15.01Z" } ] } ], directories: [ { name: "foo",
digest: { hash: "4cf2eda940...", size: 43 } } ] } // (Directory proto with hash "4cf2eda940..." and size 43) {
files: [ { name: "baz", digest: { hash: "b2c941073e...", size: 1294, }, is_executable: true } ] }
BuildBazelRemoteExecutionV2DirectoryNode
A DirectoryNode
represents a child of a Directory which is itself a Directory
and its associated metadata.
BuildBazelRemoteExecutionV2ExecutedActionMetadata
ExecutedActionMetadata contains details about a completed execution.
BuildBazelRemoteExecutionV2ExecuteOperationMetadata
Metadata about an ongoing execution, which will be contained in the metadata field of the Operation.
BuildBazelRemoteExecutionV2ExecuteRequest
A request message for Execution.Execute.
BuildBazelRemoteExecutionV2ExecuteResponse
The response message for Execution.Execute, which will be contained in the response field of the Operation.
BuildBazelRemoteExecutionV2ExecutionCapabilities
Capabilities of the remote execution system.
BuildBazelRemoteExecutionV2ExecutionPolicy
An ExecutionPolicy
can be used to control the scheduling of the action.
BuildBazelRemoteExecutionV2FileNode
A FileNode
represents a single file and associated metadata.
BuildBazelRemoteExecutionV2FindMissingBlobsRequest
A request message for ContentAddressableStorage.FindMissingBlobs.
BuildBazelRemoteExecutionV2FindMissingBlobsResponse
A response message for ContentAddressableStorage.FindMissingBlobs.
BuildBazelRemoteExecutionV2GetTreeResponse
A response message for ContentAddressableStorage.GetTree.
BuildBazelRemoteExecutionV2LogFile
A LogFile
is a log stored in the CAS.
BuildBazelRemoteExecutionV2NodeProperties
Node properties for FileNodes, DirectoryNodes, and SymlinkNodes. The server is responsible for specifying the properties that it accepts.
BuildBazelRemoteExecutionV2NodeProperty
A single property for FileNodes, DirectoryNodes, and SymlinkNodes. The server is responsible for specifying the
property name
s that it accepts. If permitted by the server, the same name
may occur multiple times.
BuildBazelRemoteExecutionV2OutputDirectory
An OutputDirectory
is the output in an ActionResult
corresponding to a directory's full contents rather than
a single file.
BuildBazelRemoteExecutionV2OutputFile
An OutputFile
is similar to a FileNode, but it is used as an output in an ActionResult
. It allows a full
file path rather than only a name.
BuildBazelRemoteExecutionV2OutputSymlink
An OutputSymlink
is similar to a Symlink, but it is used as an output in an ActionResult
. OutputSymlink
is
binary-compatible with SymlinkNode
.
BuildBazelRemoteExecutionV2Platform
A Platform
is a set of requirements, such as hardware, operating system, or compiler toolchain, for an
Action's execution environment. A Platform
is represented as a series of key-value pairs representing the
properties that are required of the platform.
BuildBazelRemoteExecutionV2PlatformProperty
A single property for the environment. The server is responsible for specifying the property name
s that it
accepts. If an unknown name
is provided in the requirements for an Action, the server SHOULD reject the
execution request. If permitted by the server, the same name
may occur multiple times. The server is also
responsible for specifying the interpretation of property value
s. For instance, a property describing how much
RAM must be available may be interpreted as allowing a worker with 16GB to fulfill a request for 8GB, while a
property describing the OS environment on which the action must be performed may require an exact match with the
worker's OS. The server MAY use the value
of one or more properties to determine how it sets up the execution
environment, such as by making specific system files available to the worker. Both names and values are
typically case-sensitive. Note that the platform is implicitly part of the action digest, so even tiny changes
in the names or values (like changing case) may result in different action cache entries.
BuildBazelRemoteExecutionV2PriorityCapabilities
Allowed values for priority in ResultsCachePolicy and ExecutionPolicy Used for querying both cache and execution valid priority ranges.
BuildBazelRemoteExecutionV2PriorityCapabilitiesPriorityRange
Supported range of priorities, including boundaries.
BuildBazelRemoteExecutionV2RequestMetadata
An optional Metadata to attach to any RPC request to tell the server about an external context of the request.
The server may use this for logging or other purposes. To use it, the client attaches the header to the call
using the canonical proto serialization: * name: build.bazel.remote.execution.v2.requestmetadata-bin
*
contents: the base64 encoded binary RequestMetadata
message. Note: the gRPC library serializes binary headers
encoded in base 64 by default (https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#requests).
Therefore, if the gRPC library is used to pass/retrieve this metadata, the user may ignore the base64 encoding
and assume it is simply serialized as a binary message.
BuildBazelRemoteExecutionV2ResultsCachePolicy
A ResultsCachePolicy
is used for fine-grained control over how action outputs are stored in the CAS and Action
Cache.
BuildBazelRemoteExecutionV2ServerCapabilities
A response message for Capabilities.GetCapabilities.
BuildBazelRemoteExecutionV2SymlinkNode
A SymlinkNode
represents a symbolic link.
BuildBazelRemoteExecutionV2ToolDetails
Details for the tool used to call the API.
BuildBazelRemoteExecutionV2Tree
A Tree
contains all the Directory protos in a single directory Merkle tree, compressed into one message.
BuildBazelRemoteExecutionV2WaitExecutionRequest
A request message for WaitExecution.
BuildBazelSemverSemVer
The full version of a given tool.
GoogleDevtoolsRemotebuildbotCommandDurations
CommandDuration contains the various duration metrics tracked when a bot performs a command.
GoogleDevtoolsRemotebuildbotCommandEvents
CommandEvents contains counters for the number of warnings and errors that occurred during the execution of a command.
GoogleDevtoolsRemotebuildbotCommandStatus
The internal status of the command result.
GoogleDevtoolsRemotebuildbotResourceUsage
ResourceUsage is the system resource usage of the host machine.
GoogleDevtoolsRemotebuildbotResourceUsageIOStats
GoogleDevtoolsRemotebuildbotResourceUsageStat
GoogleDevtoolsRemotebuildexecutionAdminV1alphaAcceleratorConfig
AcceleratorConfig defines the accelerator cards to attach to the VM.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaAutoscale
Autoscale defines the autoscaling policy of a worker pool.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaCreateInstanceRequest
The request used for CreateInstance
.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaCreateWorkerPoolRequest
The request used for CreateWorkerPool
.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaDeleteInstanceRequest
The request used for DeleteInstance
.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaDeleteWorkerPoolRequest
The request used for DeleteWorkerPool.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaFeaturePolicy
FeaturePolicy defines features allowed to be used on RBE instances, as well as instance-wide behavior changes that take effect without opt-in or opt-out at usage time.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaFeaturePolicyFeature
Defines whether a feature can be used or what values are accepted.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaGetInstanceRequest
The request used for GetInstance
.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaGetWorkerPoolRequest
The request used for GetWorkerPool.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaInstance
Instance conceptually encapsulates all Remote Build Execution resources for remote builds. An instance consists
of storage and compute resources (for example, ContentAddressableStorage
, ActionCache
, WorkerPools
) used
for running remote builds. All Remote Build Execution API calls are scoped to an instance.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaListInstancesRequest
GoogleDevtoolsRemotebuildexecutionAdminV1alphaListInstancesResponse
GoogleDevtoolsRemotebuildexecutionAdminV1alphaListWorkerPoolsRequest
GoogleDevtoolsRemotebuildexecutionAdminV1alphaListWorkerPoolsResponse
GoogleDevtoolsRemotebuildexecutionAdminV1alphaUpdateInstanceRequest
The request used for UpdateInstance
.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaUpdateWorkerPoolRequest
The request used for UpdateWorkerPool.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaWorkerConfig
Defines the configuration to be used for creating workers in the worker pool.
GoogleDevtoolsRemotebuildexecutionAdminV1alphaWorkerPool
A worker pool resource in the Remote Build Execution API.
GoogleDevtoolsRemoteworkersV1test2AdminTemp
AdminTemp is a prelimiary set of administration tasks. It's called "Temp" because we do not yet know the best
way to represent admin tasks; it's possible that this will be entirely replaced in later versions of this API.
If this message proves to be sufficient, it will be renamed in the alpha or beta release of this API. This
message (suitably marshalled into a protobuf.Any) can be used as the inline_assignment field in a lease; the
lease assignment field should simply be "admin"
in these cases. This message is heavily based on Swarming
administration tasks from the LUCI project (http://github.com/luci/luci-py/appengine/swarming).
GoogleDevtoolsRemoteworkersV1test2Blob
Describes a blob of binary content with its digest.
GoogleDevtoolsRemoteworkersV1test2CommandOutputs
DEPRECATED - use CommandResult instead. Describes the actual outputs from the task.
GoogleDevtoolsRemoteworkersV1test2CommandOverhead
DEPRECATED - use CommandResult instead. Can be used as part of CompleteRequest.metadata, or are part of a more sophisticated message.
GoogleDevtoolsRemoteworkersV1test2CommandResult
All information about the execution of a command, suitable for providing as the Bots interface's Lease.result
field.
GoogleDevtoolsRemoteworkersV1test2CommandTask
Describes a shell-style task to execute, suitable for providing as the Bots interface's Lease.payload
field.
GoogleDevtoolsRemoteworkersV1test2CommandTaskInputs
Describes the inputs to a shell-style task.
GoogleDevtoolsRemoteworkersV1test2CommandTaskInputsEnvironmentVariable
An environment variable required by this task.
GoogleDevtoolsRemoteworkersV1test2CommandTaskOutputs
Describes the expected outputs of the command.
GoogleDevtoolsRemoteworkersV1test2CommandTaskTimeouts
Describes the timeouts associated with this task.
GoogleDevtoolsRemoteworkersV1test2Digest
The CommandTask and CommandResult messages assume the existence of a service that can serve blobs of content, identified by a hash and size known as a "digest." The method by which these blobs may be retrieved is not specified here, but a model implementation is in the Remote Execution API's "ContentAddressibleStorage" interface. In the context of the RWAPI, a Digest will virtually always refer to the contents of a file or a directory. The latter is represented by the byte-encoded Directory message.
GoogleDevtoolsRemoteworkersV1test2Directory
The contents of a directory. Similar to the equivalent message in the Remote Execution API.
GoogleDevtoolsRemoteworkersV1test2DirectoryMetadata
The metadata for a directory. Similar to the equivalent message in the Remote Execution API.
GoogleDevtoolsRemoteworkersV1test2FileMetadata
The metadata for a file. Similar to the equivalent message in the Remote Execution API.
GoogleLongrunningOperation
This resource represents a long-running operation that is the result of a network API call.
GoogleRpcStatus
The Status
type defines a logical error model that is suitable for different programming environments,
including REST APIs and RPC APIs. It is used by gRPC. Each Status
message contains
three pieces of data: error code, error message, and error details. You can find out more about this error model
and how to work with it in the API Design Guide.