Default request referring to version v2 of the Remote Build Execution API. This contains the host and root path used as a starting point for constructing service requests.

View and manage your data across Google Cloud Platform services

Represents the entirety of the methods and resources available for the Remote Build Execution API service.

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, but servers SHOULD use SHA-256. 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.

See: buildBazelRemoteExecutionV2Digest smart constructor.

Creates a value of BuildBazelRemoteExecutionV2Digest with the minimum fields required to make a request.

Use one of the following lenses to modify other fields as desired:

• bbrevdSizeBytes
• bbrevdHash

The size of the blob, in bytes.

The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.

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. The error model is designed to be: - Simple to use and understand for most users - Flexible enough to meet unexpected needs # Overview The `Status` message contains three pieces of data: error code, error message, and error details. The error code should be an enum value of google.rpc.Code, but it may accept additional error codes if needed. The error message should be a developer-facing English message that helps developers *understand* and *resolve* the error. If a localized user-facing error message is needed, put the localized message in the error details or localize it in the client. The optional error details may contain arbitrary information about the error. There is a predefined set of error detail types in the package `google.rpc` that can be used for common error conditions. # Language mapping The `Status` message is the logical representation of the error model, but it is not necessarily the actual wire format. When the `Status` message is exposed in different client libraries and different wire protocols, it can be mapped differently. For example, it will likely be mapped to some exceptions in Java, but more likely mapped to some error codes in C. # Other uses The error model and the `Status` message can be used in a variety of environments, either with or without APIs, to provide a consistent developer experience across different environments. Example uses of this error model include: - Partial errors. If a service needs to return partial errors to the client, it may embed the `Status` in the normal response to indicate the partial errors. - Workflow errors. A typical workflow has multiple steps. Each step may have a `Status` message for error reporting. - Batch operations. If a client uses batch request and batch response, the `Status` message should be used directly inside batch response, one for each error sub-response. - Asynchronous operations. If an API call embeds asynchronous operation results in its response, the status of those operations should be represented directly using the `Status` message. - Logging. If some API errors are stored in logs, the message `Status` could be used directly after any stripping needed for security/privacy reasons.

See: googleRpcStatus smart constructor.

Creates a value of GoogleRpcStatus with the minimum fields required to make a request.

Use one of the following lenses to modify other fields as desired:

• grsDetails
• grsCode
• grsMessage

A list of messages that carry the error details. There is a common set of message types for APIs to use.

The status code, which should be an enum value of google.rpc.Code.

A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the google.rpc.Status.details field, or localized by the client.

The request used for GetWorkerPool.

See: googleDevtoolsRemotebuildexecutionAdminV1alphaGetWorkerPoolRequest smart constructor.

Creates a value of GoogleDevtoolsRemotebuildexecutionAdminV1alphaGetWorkerPoolRequest with the minimum fields required to make a request.

Use one of the following lenses to modify other fields as desired:

• gdravgwprName

Name of the worker pool to retrieve. Format: `projects/[PROJECT_ID]/instances/[INSTANCE_ID]/workerpools/[POOL_ID]`.

An `OutputDirectory` is the output in an `ActionResult` corresponding to a directory's full contents rather than a single file.

See: googleDevtoolsRemoteexecutionV1testOutputDirectory smart constructor.

Creates a value of GoogleDevtoolsRemoteexecutionV1testOutputDirectory with the minimum fields required to make a request.

Use one of the following lenses to modify other fields as desired:

• gdrvodPath
• gdrvodDigest
• gdrvodTreeDigest

The full path of the directory relative to the working directory. The path separator is a forward slash `/`. Since this is a relative path, it MUST NOT begin with a leading forward slash. The empty string value is allowed, and it denotes the entire working directory.

DEPRECATED: This field is deprecated and should no longer be used.

The digest of the encoded Tree proto containing the directory's contents.

An `OutputSymlink` is similar to a Symlink, but it is used as an output in an `ActionResult`. `OutputSymlink` is binary-compatible with `SymlinkNode`.

See: buildBazelRemoteExecutionV2OutputSymlink smart constructor.

Creates a value of BuildBazelRemoteExecutionV2OutputSymlink with the minimum fields required to make a request.

Use one of the following lenses to modify other fields as desired:

• bbrevosPath
• bbrevosTarget

The full path of the symlink relative to the working directory, including the filename. The path separator is a forward slash `/`. Since this is a relative path, it MUST NOT begin with a leading forward slash.

The target path of the symlink. The path separator is a forward slash `/`. The target path can be relative to the parent directory of the symlink or it can be an absolute path starting with `/`. Support for absolute paths can be checked using the Capabilities API. The canonical form forbids the substrings `/./` and `//` in the target path. `..` components are allowed anywhere in the target path.

A `Tree` contains all the Directory protos in a single directory Merkle tree, compressed into one message.

See: googleDevtoolsRemoteexecutionV1testTree smart constructor.

Creates a value of GoogleDevtoolsRemoteexecutionV1testTree with the minimum fields required to make a request.

Use one of the following lenses to modify other fields as desired:

• gdrvtChildren
• gdrvtRoot

All the child directories: the directories referred to by the root and, recursively, all its children. In order to reconstruct the directory tree, the client must take the digests of each of the child directories and then build up a tree starting from the `root`.

The root directory in the tree.

The metadata for a file. Similar to the equivalent message in the Remote Execution API.

See: googleDevtoolsRemoteworkersV1test2FileMetadata smart constructor.

Creates a value of GoogleDevtoolsRemoteworkersV1test2FileMetadata with the minimum fields required to make a request.

Use one of the following lenses to modify other fields as desired:

• gdrvfmContents
• gdrvfmPath
• gdrvfmIsExecutable
• gdrvfmDigest

If the file is small enough, its contents may also or alternatively be listed here.

The path of this file. If this message is part of the CommandOutputs.outputs fields, the path is relative to the execution root and must correspond to an entry in CommandTask.outputs.files. If this message is part of a Directory message, then the path is relative to the root of that directory. All paths MUST be delimited by forward slashes.

Properties of the file

A pointer to the contents of the file. The method by which a client retrieves the contents from a CAS system is not defined here.

Service-specific metadata associated with the operation. It typically contains progress information and common metadata such as create time. Some services might not provide such metadata. Any method that returns a long-running operation should document the metadata type, if any.

See: googleLongrunningOperationMetadata smart constructor.

Creates a value of GoogleLongrunningOperationMetadata with the minimum fields required to make a request.

Use one of the following lenses to modify other fields as desired:

• glomAddtional

Properties of the object. Contains field 'type with type URL.

Output only. State of the instance.

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.

See: googleDevtoolsRemoteworkersV1test2Digest smart constructor.

Creates a value of GoogleDevtoolsRemoteworkersV1test2Digest with the minimum fields required to make a request.

Use one of the following lenses to modify other fields as desired:

• gdrvdSizeBytes
• gdrvdHash

The size of the contents. While this is not strictly required as part of an identifier (after all, any given hash will have exactly one canonical size), it's useful in almost all cases when one might want to send or retrieve blobs of content and is included here for this reason.

A string-encoded hash (eg "1a2b3c", not the byte array [0x1a, 0x2b, 0x3c]) using an implementation-defined hash algorithm (eg SHA-256).

A response message for Capabilities.GetCapabilities.

See: buildBazelRemoteExecutionV2ServerCapabilities smart constructor.

Creates a value of BuildBazelRemoteExecutionV2ServerCapabilities with the minimum fields required to make a request.

Use one of the following lenses to modify other fields as desired:

• bbrevscHighAPIVersion
• bbrevscExecutionCapabilities
• bbrevscCacheCapabilities
• bbrevscDeprecatedAPIVersion
• bbrevscLowAPIVersion

Latest RE API version supported.

Capabilities of the remote execution system.

Capabilities of the remote cache system.

Earliest RE API version supported, including deprecated versions.

Earliest non-deprecated RE API version supported.

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.

See: buildBazelRemoteExecutionV2Action smart constructor.