docs: update generated docs (#981)
diff --git a/docs/dyn/remotebuildexecution_v2.blobs.html b/docs/dyn/remotebuildexecution_v2.blobs.html
index b40948e..2b60518 100644
--- a/docs/dyn/remotebuildexecution_v2.blobs.html
+++ b/docs/dyn/remotebuildexecution_v2.blobs.html
@@ -175,24 +175,6 @@
# ContentAddressableStorage.BatchReadBlobs.
"responses": [ # The responses to the requests.
{ # A response corresponding to a single blob that the client tried to download.
- "status": { # The `Status` type defines a logical error model that is suitable for # The result of attempting to download that blob.
- # different programming environments, including REST APIs and RPC APIs. It is
- # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors).
- "details": [ # A list of messages that carry the error details. There is a common set of
- # message types for APIs to use.
- {
- "a_key": "", # Properties of the object. Contains field @type with type URL.
- },
- ],
- "code": 42, # The status code, which should be an enum value of google.rpc.Code.
- "message": "A String", # 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.
- },
"data": "A String", # The raw binary data.
"digest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest to which this response corresponds.
# and its hash. The hash algorithm to use is defined by the server.
@@ -229,6 +211,24 @@
"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
# exactly 64 characters long.
},
+ "status": { # The `Status` type defines a logical error model that is suitable for # The result of attempting to download that blob.
+ # different programming environments, including REST APIs and RPC APIs. It is
+ # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors).
+ "message": "A String", # 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.
+ "details": [ # A list of messages that carry the error details. There is a common set of
+ # message types for APIs to use.
+ {
+ "a_key": "", # Properties of the object. Contains field @type with type URL.
+ },
+ ],
+ "code": 42, # The status code, which should be an enum value of google.rpc.Code.
+ },
},
],
}</pre>
@@ -333,6 +333,9 @@
#
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
+ "message": "A String", # 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.
"details": [ # A list of messages that carry the error details. There is a common set of
# message types for APIs to use.
{
@@ -340,9 +343,6 @@
},
],
"code": 42, # The status code, which should be an enum value of google.rpc.Code.
- "message": "A String", # 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.
},
"digest": { # A content digest. A digest for a given blob consists of the size of the blob # The blob digest to which this response corresponds.
# and its hash. The hash algorithm to use is defined by the server.
@@ -549,6 +549,10 @@
{ # A response message for
# ContentAddressableStorage.GetTree.
+ "nextPageToken": "A String", # If present, signifies that there are more results which the client can
+ # retrieve by passing this as the page_token in a subsequent
+ # request.
+ # If empty, signifies that this is the last page of results.
"directories": [ # The directories descended from the requested root.
{ # A `Directory` represents a directory node in a file tree, containing zero or
# more children FileNodes,
@@ -626,78 +630,6 @@
# ]
# }
# ```
- "symlinks": [ # The symlinks in the directory.
- { # A `SymlinkNode` represents a symbolic link.
- "nodeProperties": [ # The node properties of the SymlinkNode.
- { # 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.
- "value": "A String", # The property value.
- "name": "A String", # The property name.
- },
- ],
- "name": "A String", # The name of the symlink.
- "target": "A String", # 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.
- },
- ],
- "files": [ # The files in the directory.
- { # A `FileNode` represents a single file and associated metadata.
- "nodeProperties": [ # The node properties of the FileNode.
- { # 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.
- "value": "A String", # The property value.
- "name": "A String", # The property name.
- },
- ],
- "name": "A String", # The name of the file.
- "digest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the file's content.
- # 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.
- "sizeBytes": "A String", # The size of the blob, in bytes.
- "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
- # exactly 64 characters long.
- },
- "isExecutable": True or False, # True if file is executable, false otherwise.
- },
- ],
"directories": [ # The subdirectories in the directory.
{ # A `DirectoryNode` represents a child of a
# Directory which is itself
@@ -743,22 +675,90 @@
},
},
],
+ "files": [ # The files in the directory.
+ { # A `FileNode` represents a single file and associated metadata.
+ "nodeProperties": [ # The node properties of the FileNode.
+ { # 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.
+ "name": "A String", # The property name.
+ "value": "A String", # The property value.
+ },
+ ],
+ "isExecutable": True or False, # True if file is executable, false otherwise.
+ "digest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the file's content.
+ # 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.
+ "sizeBytes": "A String", # The size of the blob, in bytes.
+ "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+ # exactly 64 characters long.
+ },
+ "name": "A String", # The name of the file.
+ },
+ ],
"nodeProperties": [ # The node properties of the Directory.
{ # 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.
- "value": "A String", # The property value.
"name": "A String", # The property name.
+ "value": "A String", # The property value.
+ },
+ ],
+ "symlinks": [ # The symlinks in the directory.
+ { # A `SymlinkNode` represents a symbolic link.
+ "name": "A String", # The name of the symlink.
+ "nodeProperties": [ # The node properties of the SymlinkNode.
+ { # 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.
+ "name": "A String", # The property name.
+ "value": "A String", # The property value.
+ },
+ ],
+ "target": "A String", # 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.
},
],
},
],
- "nextPageToken": "A String", # If present, signifies that there are more results which the client can
- # retrieve by passing this as the page_token in a subsequent
- # request.
- # If empty, signifies that this is the last page of results.
}</pre>
</div>