You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
742 lines
36 KiB
742 lines
36 KiB
<html><body>
|
|
<style>
|
|
|
|
body, h1, h2, h3, div, span, p, pre, a {
|
|
margin: 0;
|
|
padding: 0;
|
|
border: 0;
|
|
font-weight: inherit;
|
|
font-style: inherit;
|
|
font-size: 100%;
|
|
font-family: inherit;
|
|
vertical-align: baseline;
|
|
}
|
|
|
|
body {
|
|
font-size: 13px;
|
|
padding: 1em;
|
|
}
|
|
|
|
h1 {
|
|
font-size: 26px;
|
|
margin-bottom: 1em;
|
|
}
|
|
|
|
h2 {
|
|
font-size: 24px;
|
|
margin-bottom: 1em;
|
|
}
|
|
|
|
h3 {
|
|
font-size: 20px;
|
|
margin-bottom: 1em;
|
|
margin-top: 1em;
|
|
}
|
|
|
|
pre, code {
|
|
line-height: 1.5;
|
|
font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Lucida Console', monospace;
|
|
}
|
|
|
|
pre {
|
|
margin-top: 0.5em;
|
|
}
|
|
|
|
h1, h2, h3, p {
|
|
font-family: Arial, sans serif;
|
|
}
|
|
|
|
h1, h2, h3 {
|
|
border-bottom: solid #CCC 1px;
|
|
}
|
|
|
|
.toc_element {
|
|
margin-top: 0.5em;
|
|
}
|
|
|
|
.firstline {
|
|
margin-left: 2 em;
|
|
}
|
|
|
|
.method {
|
|
margin-top: 1em;
|
|
border: solid 1px #CCC;
|
|
padding: 1em;
|
|
background: #EEE;
|
|
}
|
|
|
|
.details {
|
|
font-weight: bold;
|
|
font-size: 14px;
|
|
}
|
|
|
|
</style>
|
|
|
|
<h1><a href="remotebuildexecution_v2.html">Remote Build Execution API</a> . <a href="remotebuildexecution_v2.blobs.html">blobs</a></h1>
|
|
<h2>Instance Methods</h2>
|
|
<p class="toc_element">
|
|
<code><a href="#batchRead">batchRead(instanceName, body, x__xgafv=None)</a></code></p>
|
|
<p class="firstline">Download many blobs at once.</p>
|
|
<p class="toc_element">
|
|
<code><a href="#batchUpdate">batchUpdate(instanceName, body, x__xgafv=None)</a></code></p>
|
|
<p class="firstline">Upload many blobs at once.</p>
|
|
<p class="toc_element">
|
|
<code><a href="#findMissing">findMissing(instanceName, body, x__xgafv=None)</a></code></p>
|
|
<p class="firstline">Determine if blobs are present in the CAS.</p>
|
|
<p class="toc_element">
|
|
<code><a href="#getTree">getTree(instanceName, hash, sizeBytes, pageSize=None, pageToken=None, x__xgafv=None)</a></code></p>
|
|
<p class="firstline">Fetch the entire directory tree rooted at a node.</p>
|
|
<p class="toc_element">
|
|
<code><a href="#getTree_next">getTree_next(previous_request, previous_response)</a></code></p>
|
|
<p class="firstline">Retrieves the next page of results.</p>
|
|
<h3>Method Details</h3>
|
|
<div class="method">
|
|
<code class="details" id="batchRead">batchRead(instanceName, body, x__xgafv=None)</code>
|
|
<pre>Download many blobs at once.
|
|
|
|
The server may enforce a limit of the combined total size of blobs
|
|
to be downloaded using this API. This limit may be obtained using the
|
|
Capabilities API.
|
|
Requests exceeding the limit should either be split into smaller
|
|
chunks or downloaded using the
|
|
ByteStream API, as appropriate.
|
|
|
|
This request is equivalent to calling a Bytestream `Read` request
|
|
on each individual blob, in parallel. The requests may succeed or fail
|
|
independently.
|
|
|
|
Errors:
|
|
|
|
* `INVALID_ARGUMENT`: The client attempted to read more than the
|
|
server supported limit.
|
|
|
|
Every error on individual read will be returned in the corresponding digest
|
|
status.
|
|
|
|
Args:
|
|
instanceName: string, The instance of the execution system to operate against. A server may
|
|
support multiple instances of the execution system (with their own workers,
|
|
storage, caches, etc.). The server MAY require use of this field to select
|
|
between them in an implementation-defined fashion, otherwise it can be
|
|
omitted. (required)
|
|
body: object, The request body. (required)
|
|
The object takes the form of:
|
|
|
|
{ # A request message for
|
|
# ContentAddressableStorage.BatchReadBlobs.
|
|
"digests": [ # The individual blob digests.
|
|
{ # 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.
|
|
"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.
|
|
},
|
|
],
|
|
}
|
|
|
|
x__xgafv: string, V1 error format.
|
|
Allowed values
|
|
1 - v1 error format
|
|
2 - v2 error format
|
|
|
|
Returns:
|
|
An object of the form:
|
|
|
|
{ # A response message for
|
|
# 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).
|
|
"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.
|
|
"code": 42, # The status code, which should be an enum value of google.rpc.Code.
|
|
"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.
|
|
},
|
|
],
|
|
},
|
|
"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, 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.
|
|
"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.
|
|
},
|
|
},
|
|
],
|
|
}</pre>
|
|
</div>
|
|
|
|
<div class="method">
|
|
<code class="details" id="batchUpdate">batchUpdate(instanceName, body, x__xgafv=None)</code>
|
|
<pre>Upload many blobs at once.
|
|
|
|
The server may enforce a limit of the combined total size of blobs
|
|
to be uploaded using this API. This limit may be obtained using the
|
|
Capabilities API.
|
|
Requests exceeding the limit should either be split into smaller
|
|
chunks or uploaded using the
|
|
ByteStream API, as appropriate.
|
|
|
|
This request is equivalent to calling a Bytestream `Write` request
|
|
on each individual blob, in parallel. The requests may succeed or fail
|
|
independently.
|
|
|
|
Errors:
|
|
|
|
* `INVALID_ARGUMENT`: The client attempted to upload more than the
|
|
server supported limit.
|
|
|
|
Individual requests may return the following errors, additionally:
|
|
|
|
* `RESOURCE_EXHAUSTED`: There is insufficient disk quota to store the blob.
|
|
* `INVALID_ARGUMENT`: The
|
|
Digest does not match the
|
|
provided data.
|
|
|
|
Args:
|
|
instanceName: string, The instance of the execution system to operate against. A server may
|
|
support multiple instances of the execution system (with their own workers,
|
|
storage, caches, etc.). The server MAY require use of this field to select
|
|
between them in an implementation-defined fashion, otherwise it can be
|
|
omitted. (required)
|
|
body: object, The request body. (required)
|
|
The object takes the form of:
|
|
|
|
{ # A request message for
|
|
# ContentAddressableStorage.BatchUpdateBlobs.
|
|
"requests": [ # The individual upload requests.
|
|
{ # A request corresponding to a single blob that the client wants to upload.
|
|
"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 of the blob. This MUST be the digest of `data`.
|
|
# 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.
|
|
"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.
|
|
},
|
|
},
|
|
],
|
|
}
|
|
|
|
x__xgafv: string, V1 error format.
|
|
Allowed values
|
|
1 - v1 error format
|
|
2 - v2 error format
|
|
|
|
Returns:
|
|
An object of the form:
|
|
|
|
{ # A response message for
|
|
# ContentAddressableStorage.BatchUpdateBlobs.
|
|
"responses": [ # The responses to the requests.
|
|
{ # A response corresponding to a single blob that the client tried to upload.
|
|
"status": { # The `Status` type defines a logical error model that is suitable for # The result of attempting to upload 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.
|
|
"code": 42, # The status code, which should be an enum value of google.rpc.Code.
|
|
"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.
|
|
},
|
|
],
|
|
},
|
|
"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, 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.
|
|
"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.
|
|
},
|
|
},
|
|
],
|
|
}</pre>
|
|
</div>
|
|
|
|
<div class="method">
|
|
<code class="details" id="findMissing">findMissing(instanceName, body, x__xgafv=None)</code>
|
|
<pre>Determine if blobs are present in the CAS.
|
|
|
|
Clients can use this API before uploading blobs to determine which ones are
|
|
already present in the CAS and do not need to be uploaded again.
|
|
|
|
There are no method-specific errors.
|
|
|
|
Args:
|
|
instanceName: string, The instance of the execution system to operate against. A server may
|
|
support multiple instances of the execution system (with their own workers,
|
|
storage, caches, etc.). The server MAY require use of this field to select
|
|
between them in an implementation-defined fashion, otherwise it can be
|
|
omitted. (required)
|
|
body: object, The request body. (required)
|
|
The object takes the form of:
|
|
|
|
{ # A request message for
|
|
# ContentAddressableStorage.FindMissingBlobs.
|
|
"blobDigests": [ # A list of the blobs to check.
|
|
{ # 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.
|
|
"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.
|
|
},
|
|
],
|
|
}
|
|
|
|
x__xgafv: string, V1 error format.
|
|
Allowed values
|
|
1 - v1 error format
|
|
2 - v2 error format
|
|
|
|
Returns:
|
|
An object of the form:
|
|
|
|
{ # A response message for
|
|
# ContentAddressableStorage.FindMissingBlobs.
|
|
"missingBlobDigests": [ # A list of the blobs requested *not* present in the storage.
|
|
{ # 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.
|
|
"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.
|
|
},
|
|
],
|
|
}</pre>
|
|
</div>
|
|
|
|
<div class="method">
|
|
<code class="details" id="getTree">getTree(instanceName, hash, sizeBytes, pageSize=None, pageToken=None, x__xgafv=None)</code>
|
|
<pre>Fetch the entire directory tree rooted at a node.
|
|
|
|
This request must be targeted at a
|
|
Directory stored in the
|
|
ContentAddressableStorage
|
|
(CAS). The server will enumerate the `Directory` tree recursively and
|
|
return every node descended from the root.
|
|
|
|
The GetTreeRequest.page_token parameter can be used to skip ahead in
|
|
the stream (e.g. when retrying a partially completed and aborted request),
|
|
by setting it to a value taken from GetTreeResponse.next_page_token of the
|
|
last successfully processed GetTreeResponse).
|
|
|
|
The exact traversal order is unspecified and, unless retrieving subsequent
|
|
pages from an earlier request, is not guaranteed to be stable across
|
|
multiple invocations of `GetTree`.
|
|
|
|
If part of the tree is missing from the CAS, the server will return the
|
|
portion present and omit the rest.
|
|
|
|
* `NOT_FOUND`: The requested tree root is not present in the CAS.
|
|
|
|
Args:
|
|
instanceName: string, The instance of the execution system to operate against. A server may
|
|
support multiple instances of the execution system (with their own workers,
|
|
storage, caches, etc.). The server MAY require use of this field to select
|
|
between them in an implementation-defined fashion, otherwise it can be
|
|
omitted. (required)
|
|
hash: string, The hash. In the case of SHA-256, it will always be a lowercase hex string
|
|
exactly 64 characters long. (required)
|
|
sizeBytes: string, The size of the blob, in bytes. (required)
|
|
pageSize: integer, A maximum page size to request. If present, the server will request no more
|
|
than this many items. Regardless of whether a page size is specified, the
|
|
server may place its own limit on the number of items to be returned and
|
|
require the client to retrieve more items using a subsequent request.
|
|
pageToken: string, A page token, which must be a value received in a previous
|
|
GetTreeResponse.
|
|
If present, the server will use it to return the following page of results.
|
|
x__xgafv: string, V1 error format.
|
|
Allowed values
|
|
1 - v1 error format
|
|
2 - v2 error format
|
|
|
|
Returns:
|
|
An object of the form:
|
|
|
|
{ # 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,
|
|
# 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.
|
|
#
|
|
# 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
|
|
# }
|
|
# }
|
|
# ],
|
|
# 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
|
|
# }
|
|
# ]
|
|
# }
|
|
# ```
|
|
"symlinks": [ # The symlinks in the directory.
|
|
{ # A `SymlinkNode` represents a symbolic link.
|
|
"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.
|
|
"isExecutable": True or False, # True if file is executable, false otherwise.
|
|
"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, 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.
|
|
"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.
|
|
},
|
|
},
|
|
],
|
|
"directories": [ # The subdirectories in the directory.
|
|
{ # A `DirectoryNode` represents a child of a
|
|
# Directory which is itself
|
|
# a `Directory` and its associated metadata.
|
|
"name": "A String", # The name of the directory.
|
|
"digest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the
|
|
# Directory object
|
|
# represented. See Digest
|
|
# for information about how to take the digest of a proto message.
|
|
# 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.
|
|
"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.
|
|
},
|
|
},
|
|
],
|
|
},
|
|
],
|
|
}</pre>
|
|
</div>
|
|
|
|
<div class="method">
|
|
<code class="details" id="getTree_next">getTree_next(previous_request, previous_response)</code>
|
|
<pre>Retrieves the next page of results.
|
|
|
|
Args:
|
|
previous_request: The request for the previous page. (required)
|
|
previous_response: The response from the request for the previous page. (required)
|
|
|
|
Returns:
|
|
A request object that you can call 'execute()' on to request the next
|
|
page. Returns None if there are no more items in the collection.
|
|
</pre>
|
|
</div>
|
|
|
|
</body></html> |