Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / python / google-api-python-client / 32d1c597b364e2641eca33ccf6df802bb218eea1 / . / docs / dyn / remotebuildexecution_v2.blobs.html
blob: 38fd3c487141c6ccb18684e9ed4b85fe9dc2cf81 [file] [log] [blame]
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]1<html><body>
2<style>
3
4body, h1, h2, h3, div, span, p, pre, a {
5 margin: 0;
6 padding: 0;
7 border: 0;
8 font-weight: inherit;
9 font-style: inherit;
10 font-size: 100%;
11 font-family: inherit;
12 vertical-align: baseline;
13}
14
15body {
16 font-size: 13px;
17 padding: 1em;
18}
19
20h1 {
21 font-size: 26px;
22 margin-bottom: 1em;
23}
24
25h2 {
26 font-size: 24px;
27 margin-bottom: 1em;
28}
29
30h3 {
31 font-size: 20px;
32 margin-bottom: 1em;
33 margin-top: 1em;
34}
35
36pre, code {
37 line-height: 1.5;
38 font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Lucida Console', monospace;
39}
40
41pre {
42 margin-top: 0.5em;
43}
44
45h1, h2, h3, p {
46 font-family: Arial, sans serif;
47}
48
49h1, h2, h3 {
50 border-bottom: solid #CCC 1px;
51}
52
53.toc_element {
54 margin-top: 0.5em;
55}
56
57.firstline {
58 margin-left: 2 em;
59}
60
61.method {
62 margin-top: 1em;
63 border: solid 1px #CCC;
64 padding: 1em;
65 background: #EEE;
66}
67
68.details {
69 font-weight: bold;
70 font-size: 14px;
71}
72
73</style>
74
75<h1><a href="remotebuildexecution_v2.html">Remote Build Execution API</a> . <a href="remotebuildexecution_v2.blobs.html">blobs</a></h1>
76<h2>Instance Methods</h2>
77<p class="toc_element">
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]78 <code><a href="#batchRead">batchRead(instanceName, body=None, x__xgafv=None)</a></code></p>
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]79<p class="firstline">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.</p>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]80<p class="toc_element">
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]81 <code><a href="#batchUpdate">batchUpdate(instanceName, body=None, x__xgafv=None)</a></code></p>
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]82<p class="firstline">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.</p>
83<p class="toc_element">
84 <code><a href="#close">close()</a></code></p>
85<p class="firstline">Close httplib2 connections.</p>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]86<p class="toc_element">
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]87 <code><a href="#findMissing">findMissing(instanceName, body=None, x__xgafv=None)</a></code></p>
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]88<p class="firstline">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. Servers SHOULD increase the TTLs of the referenced blobs if necessary and applicable. There are no method-specific errors.</p>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]89<p class="toc_element">
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]90 <code><a href="#getTree">getTree(instanceName, hash, sizeBytes, pageToken=None, pageSize=None, x__xgafv=None)</a></code></p>
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]91<p class="firstline">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. Errors: * `NOT_FOUND`: The requested tree root is not present in the CAS.</p>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]92<p class="toc_element">
93 <code><a href="#getTree_next">getTree_next(previous_request, previous_response)</a></code></p>
94<p class="firstline">Retrieves the next page of results.</p>
95<h3>Method Details</h3>
96<div class="method">
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]97 <code class="details" id="batchRead">batchRead(instanceName, body=None, x__xgafv=None)</code>
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]98 <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.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]99
100Args:
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]101 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)
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]102 body: object, The request body.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]103 The object takes the form of:
104
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]105{ # A request message for ContentAddressableStorage.BatchReadBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame]106 &quot;digests&quot;: [ # The individual blob digests.
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]107 { # 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.
Yoshi Automation Bot0d561ef2020-11-25 07:50:41 -0800[diff] [blame]108 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]109 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]110 },
111 ],
112 }
113
114 x__xgafv: string, V1 error format.
115 Allowed values
116 1 - v1 error format
117 2 - v2 error format
118
119Returns:
120 An object of the form:
121
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]122 { # A response message for ContentAddressableStorage.BatchReadBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame]123 &quot;responses&quot;: [ # The responses to the requests.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]124 { # A response corresponding to a single blob that the client tried to download.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]125 &quot;digest&quot;: { # 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. # The digest to which this response corresponds.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]126 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]127 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]128 },
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]129 &quot;data&quot;: &quot;A String&quot;, # The raw binary data.
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]130 &quot;status&quot;: { # 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](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). # The result of attempting to download that blob.
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]131 &quot;details&quot;: [ # A list of messages that carry the error details. There is a common set of message types for APIs to use.
Bu Sun Kimd059ad82020-07-22 17:02:09 -0700[diff] [blame]132 {
133 &quot;a_key&quot;: &quot;&quot;, # Properties of the object. Contains field @type with type URL.
134 },
135 ],
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]136 &quot;code&quot;: 42, # The status code, which should be an enum value of google.rpc.Code.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]137 &quot;message&quot;: &quot;A String&quot;, # 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.
Yoshi Automation Bot0d561ef2020-11-25 07:50:41 -0800[diff] [blame]138 },
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]139 },
140 ],
141 }</pre>
142</div>
143
144<div class="method">
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]145 <code class="details" id="batchUpdate">batchUpdate(instanceName, body=None, x__xgafv=None)</code>
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]146 <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.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]147
148Args:
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]149 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)
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]150 body: object, The request body.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]151 The object takes the form of:
152
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]153{ # A request message for ContentAddressableStorage.BatchUpdateBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame]154 &quot;requests&quot;: [ # The individual upload requests.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]155 { # A request corresponding to a single blob that the client wants to upload.
Yoshi Automation Bot0d561ef2020-11-25 07:50:41 -0800[diff] [blame]156 &quot;digest&quot;: { # 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. # The digest of the blob. This MUST be the digest of `data`.
Yoshi Automation Bot0d561ef2020-11-25 07:50:41 -0800[diff] [blame]157 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]158 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
Yoshi Automation Bot0d561ef2020-11-25 07:50:41 -0800[diff] [blame]159 },
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]160 &quot;data&quot;: &quot;A String&quot;, # The raw binary data.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]161 },
162 ],
163 }
164
165 x__xgafv: string, V1 error format.
166 Allowed values
167 1 - v1 error format
168 2 - v2 error format
169
170Returns:
171 An object of the form:
172
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]173 { # A response message for ContentAddressableStorage.BatchUpdateBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame]174 &quot;responses&quot;: [ # The responses to the requests.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]175 { # A response corresponding to a single blob that the client tried to upload.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]176 &quot;digest&quot;: { # 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. # The blob digest to which this response corresponds.
177 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
178 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
179 },
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]180 &quot;status&quot;: { # 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](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). # The result of attempting to upload that blob.
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]181 &quot;details&quot;: [ # A list of messages that carry the error details. There is a common set of message types for APIs to use.
Bu Sun Kim4ed7d3f2020-05-27 12:20:54 -0700[diff] [blame]182 {
183 &quot;a_key&quot;: &quot;&quot;, # Properties of the object. Contains field @type with type URL.
184 },
185 ],
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]186 &quot;code&quot;: 42, # The status code, which should be an enum value of google.rpc.Code.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]187 &quot;message&quot;: &quot;A String&quot;, # 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.
Bu Sun Kim4ed7d3f2020-05-27 12:20:54 -0700[diff] [blame]188 },
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]189 },
190 ],
191 }</pre>
192</div>
193
194<div class="method">
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]195 <code class="details" id="close">close()</code>
196 <pre>Close httplib2 connections.</pre>
197</div>
198
199<div class="method">
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]200 <code class="details" id="findMissing">findMissing(instanceName, body=None, x__xgafv=None)</code>
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]201 <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. Servers SHOULD increase the TTLs of the referenced blobs if necessary and applicable. There are no method-specific errors.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]202
203Args:
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]204 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)
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]205 body: object, The request body.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]206 The object takes the form of:
207
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]208{ # A request message for ContentAddressableStorage.FindMissingBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame]209 &quot;blobDigests&quot;: [ # A list of the blobs to check.
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]210 { # 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.
Yoshi Automation Bot0d561ef2020-11-25 07:50:41 -0800[diff] [blame]211 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]212 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]213 },
214 ],
215 }
216
217 x__xgafv: string, V1 error format.
218 Allowed values
219 1 - v1 error format
220 2 - v2 error format
221
222Returns:
223 An object of the form:
224
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]225 { # A response message for ContentAddressableStorage.FindMissingBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame]226 &quot;missingBlobDigests&quot;: [ # A list of the blobs requested *not* present in the storage.
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]227 { # 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.
Yoshi Automation Bot0d561ef2020-11-25 07:50:41 -0800[diff] [blame]228 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]229 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]230 },
231 ],
232 }</pre>
233</div>
234
235<div class="method">
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]236 <code class="details" id="getTree">getTree(instanceName, hash, sizeBytes, pageToken=None, pageSize=None, x__xgafv=None)</code>
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]237 <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. Errors: * `NOT_FOUND`: The requested tree root is not present in the CAS.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]238
239Args:
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]240 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)
241 hash: string, The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long. (required)
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]242 sizeBytes: string, The size of the blob, in bytes. (required)
Yoshi Automation Bot0d561ef2020-11-25 07:50:41 -0800[diff] [blame]243 pageToken: string, A page token, which must be a value received in a previous GetTreeResponse. If present, the server will use that token as an offset, returning only that page and the ones that succeed it.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]244 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.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]245 x__xgafv: string, V1 error format.
246 Allowed values
247 1 - v1 error format
248 2 - v2 error format
249
250Returns:
251 An object of the form:
252
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]253 { # A response message for ContentAddressableStorage.GetTree.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame]254 &quot;directories&quot;: [ # The directories descended from the requested root.
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]255 { # 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 &quot;Foo&quot; and &quot;foo&quot; 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: &quot;bar&quot;, digest: { hash: &quot;4a73bc9d03...&quot;, size: 65534 }, node_properties: [ { &quot;name&quot;: &quot;MTime&quot;, &quot;value&quot;: &quot;2017-01-15T01:30:15.01Z&quot; } ] } ], directories: [ { name: &quot;foo&quot;, digest: { hash: &quot;4cf2eda940...&quot;, size: 43 } } ] } // (Directory proto with hash &quot;4cf2eda940...&quot; and size 43) { files: [ { name: &quot;baz&quot;, digest: { hash: &quot;b2c941073e...&quot;, size: 1294, }, is_executable: true } ] } ```
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]256 &quot;nodeProperties&quot;: [ # The node properties of the Directory.
257 { # 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.
258 &quot;name&quot;: &quot;A String&quot;, # The property name.
259 &quot;value&quot;: &quot;A String&quot;, # The property value.
260 },
261 ],
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame]262 &quot;directories&quot;: [ # The subdirectories in the directory.
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]263 { # A `DirectoryNode` represents a child of a Directory which is itself a `Directory` and its associated metadata.
Dmitry Frenkel3e17f892020-10-06 16:46:05 -0700[diff] [blame]264 &quot;digest&quot;: { # 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. # The digest of the Directory object represented. See Digest for information about how to take the digest of a proto message.
Bu Sun Kim673ec5c2020-11-16 11:05:03 -0700[diff] [blame]265 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]266 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]267 },
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]268 &quot;name&quot;: &quot;A String&quot;, # The name of the directory.
Bu Sun Kimd059ad82020-07-22 17:02:09 -0700[diff] [blame]269 },
270 ],
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]271 &quot;symlinks&quot;: [ # The symlinks in the directory.
272 { # A `SymlinkNode` represents a symbolic link.
273 &quot;nodeProperties&quot;: [ # The node properties of the SymlinkNode.
274 { # 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.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]275 &quot;name&quot;: &quot;A String&quot;, # The property name.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]276 &quot;value&quot;: &quot;A String&quot;, # The property value.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]277 },
278 ],
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]279 &quot;target&quot;: &quot;A String&quot;, # 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.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]280 &quot;name&quot;: &quot;A String&quot;, # The name of the symlink.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]281 },
282 ],
283 &quot;files&quot;: [ # The files in the directory.
284 { # A `FileNode` represents a single file and associated metadata.
285 &quot;digest&quot;: { # 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. # The digest of the file&#x27;s content.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]286 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]287 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]288 },
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]289 &quot;name&quot;: &quot;A String&quot;, # The name of the file.
290 &quot;nodeProperties&quot;: [ # The node properties of the FileNode.
291 { # 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.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]292 &quot;name&quot;: &quot;A String&quot;, # The property name.
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]293 &quot;value&quot;: &quot;A String&quot;, # The property value.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]294 },
295 ],
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]296 &quot;isExecutable&quot;: True or False, # True if file is executable, false otherwise.
Yoshi Automation Botb6971b02020-11-26 17:16:03 -0800[diff] [blame]297 },
298 ],
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]299 },
300 ],
Yoshi Automation Bot0bf565c2020-12-09 08:56:03 -0800[diff] [blame]301 &quot;nextPageToken&quot;: &quot;A String&quot;, # 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.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]302 }</pre>
303</div>
304
305<div class="method">
306 <code class="details" id="getTree_next">getTree_next(previous_request, previous_response)</code>
307 <pre>Retrieves the next page of results.
308
309Args:
310 previous_request: The request for the previous page. (required)
311 previous_response: The response from the request for the previous page. (required)
312
313Returns:
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame]314 A request object that you can call &#x27;execute()&#x27; on to request the next
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]315 page. Returns None if there are no more items in the collection.
316 </pre>
317</div>
318
319</body></html>