Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / python / google-api-python-client / 650209194f8080f37a5f20846931790f4c70ed46 / . / docs / dyn / remotebuildexecution_v2.blobs.html
blob: ceb59b8cb804115acd56c7fd2646be790ffd2af1 [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>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]79<p class="firstline">Download many blobs at once.</p>
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>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]82<p class="firstline">Upload many blobs at once.</p>
83<p class="toc_element">
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]84 <code><a href="#findMissing">findMissing(instanceName, body=None, x__xgafv=None)</a></code></p>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]85<p class="firstline">Determine if blobs are present in the CAS.</p>
86<p class="toc_element">
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]87 <code><a href="#getTree">getTree(instanceName, hash, sizeBytes, pageToken=None, pageSize=None, x__xgafv=None)</a></code></p>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]88<p class="firstline">Fetch the entire directory tree rooted at a node.</p>
89<p class="toc_element">
90 <code><a href="#getTree_next">getTree_next(previous_request, previous_response)</a></code></p>
91<p class="firstline">Retrieves the next page of results.</p>
92<h3>Method Details</h3>
93<div class="method">
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]94 <code class="details" id="batchRead">batchRead(instanceName, body=None, x__xgafv=None)</code>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]95 <pre>Download many blobs at once.
96
97The server may enforce a limit of the combined total size of blobs
98to be downloaded using this API. This limit may be obtained using the
99Capabilities API.
100Requests exceeding the limit should either be split into smaller
101chunks or downloaded using the
102ByteStream API, as appropriate.
103
104This request is equivalent to calling a Bytestream `Read` request
105on each individual blob, in parallel. The requests may succeed or fail
106independently.
107
108Errors:
109
110* `INVALID_ARGUMENT`: The client attempted to read more than the
111 server supported limit.
112
113Every error on individual read will be returned in the corresponding digest
114status.
115
116Args:
117 instanceName: string, The instance of the execution system to operate against. A server may
118support multiple instances of the execution system (with their own workers,
119storage, caches, etc.). The server MAY require use of this field to select
120between them in an implementation-defined fashion, otherwise it can be
121omitted. (required)
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]122 body: object, The request body.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]123 The object takes the form of:
124
125{ # A request message for
126 # ContentAddressableStorage.BatchReadBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]127 &quot;digests&quot;: [ # The individual blob digests.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]128 { # A content digest. A digest for a given blob consists of the size of the blob
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]129 # and its hash. The hash algorithm to use is defined by the server.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]130 #
131 # The size is considered to be an integral part of the digest and cannot be
132 # separated. That is, even if the `hash` field is correctly specified but
133 # `size_bytes` is not, the server MUST reject the request.
134 #
135 # The reason for including the size in the digest is as follows: in a great
136 # many cases, the server needs to know the size of the blob it is about to work
137 # with prior to starting an operation with it, such as flattening Merkle tree
138 # structures or streaming it to a worker. Technically, the server could
139 # implement a separate metadata store, but this results in a significantly more
140 # complicated implementation as opposed to having the client specify the size
141 # up-front (or storing the size along with the digest in every message where
142 # digests are embedded). This does mean that the API leaks some implementation
143 # details of (what we consider to be) a reasonable server implementation, but
144 # we consider this to be a worthwhile tradeoff.
145 #
146 # When a `Digest` is used to refer to a proto message, it always refers to the
147 # message in binary encoded form. To ensure consistent hashing, clients and
148 # servers MUST ensure that they serialize messages according to the following
149 # rules, even if there are alternate valid encodings for the same message:
150 #
151 # * Fields are serialized in tag order.
152 # * There are no unknown fields.
153 # * There are no duplicate fields.
154 # * Fields are serialized according to the default semantics for their type.
155 #
156 # Most protocol buffer implementations will always follow these rules when
157 # serializing, but care should be taken to avoid shortcuts. For instance,
158 # concatenating two messages to merge them may produce duplicate fields.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]159 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
160 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]161 # exactly 64 characters long.
162 },
163 ],
164 }
165
166 x__xgafv: string, V1 error format.
167 Allowed values
168 1 - v1 error format
169 2 - v2 error format
170
171Returns:
172 An object of the form:
173
174 { # A response message for
175 # ContentAddressableStorage.BatchReadBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]176 &quot;responses&quot;: [ # The responses to the requests.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]177 { # A response corresponding to a single blob that the client tried to download.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]178 &quot;status&quot;: { # The `Status` type defines a logical error model that is suitable for # The result of attempting to download that blob.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]179 # different programming environments, including REST APIs and RPC APIs. It is
180 # used by [gRPC](https://github.com/grpc). Each `Status` message contains
181 # three pieces of data: error code, error message, and error details.
182 #
183 # You can find out more about this error model and how to work with it in the
184 # [API Design Guide](https://cloud.google.com/apis/design/errors).
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]185 &quot;code&quot;: 42, # The status code, which should be an enum value of google.rpc.Code.
186 &quot;message&quot;: &quot;A String&quot;, # A developer-facing error message, which should be in English. Any
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]187 # user-facing error message should be localized and sent in the
188 # google.rpc.Status.details field, or localized by the client.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]189 &quot;details&quot;: [ # A list of messages that carry the error details. There is a common set of
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]190 # message types for APIs to use.
191 {
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]192 &quot;a_key&quot;: &quot;&quot;, # Properties of the object. Contains field @type with type URL.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]193 },
194 ],
195 },
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]196 &quot;data&quot;: &quot;A String&quot;, # The raw binary data.
197 &quot;digest&quot;: { # A content digest. A digest for a given blob consists of the size of the blob # The digest to which this response corresponds.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]198 # and its hash. The hash algorithm to use is defined by the server.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]199 #
200 # The size is considered to be an integral part of the digest and cannot be
201 # separated. That is, even if the `hash` field is correctly specified but
202 # `size_bytes` is not, the server MUST reject the request.
203 #
204 # The reason for including the size in the digest is as follows: in a great
205 # many cases, the server needs to know the size of the blob it is about to work
206 # with prior to starting an operation with it, such as flattening Merkle tree
207 # structures or streaming it to a worker. Technically, the server could
208 # implement a separate metadata store, but this results in a significantly more
209 # complicated implementation as opposed to having the client specify the size
210 # up-front (or storing the size along with the digest in every message where
211 # digests are embedded). This does mean that the API leaks some implementation
212 # details of (what we consider to be) a reasonable server implementation, but
213 # we consider this to be a worthwhile tradeoff.
214 #
215 # When a `Digest` is used to refer to a proto message, it always refers to the
216 # message in binary encoded form. To ensure consistent hashing, clients and
217 # servers MUST ensure that they serialize messages according to the following
218 # rules, even if there are alternate valid encodings for the same message:
219 #
220 # * Fields are serialized in tag order.
221 # * There are no unknown fields.
222 # * There are no duplicate fields.
223 # * Fields are serialized according to the default semantics for their type.
224 #
225 # Most protocol buffer implementations will always follow these rules when
226 # serializing, but care should be taken to avoid shortcuts. For instance,
227 # concatenating two messages to merge them may produce duplicate fields.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]228 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
229 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]230 # exactly 64 characters long.
231 },
232 },
233 ],
234 }</pre>
235</div>
236
237<div class="method">
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]238 <code class="details" id="batchUpdate">batchUpdate(instanceName, body=None, x__xgafv=None)</code>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]239 <pre>Upload many blobs at once.
240
241The server may enforce a limit of the combined total size of blobs
242to be uploaded using this API. This limit may be obtained using the
243Capabilities API.
244Requests exceeding the limit should either be split into smaller
245chunks or uploaded using the
246ByteStream API, as appropriate.
247
248This request is equivalent to calling a Bytestream `Write` request
249on each individual blob, in parallel. The requests may succeed or fail
250independently.
251
252Errors:
253
254* `INVALID_ARGUMENT`: The client attempted to upload more than the
255 server supported limit.
256
257Individual requests may return the following errors, additionally:
258
259* `RESOURCE_EXHAUSTED`: There is insufficient disk quota to store the blob.
260* `INVALID_ARGUMENT`: The
261Digest does not match the
262provided data.
263
264Args:
265 instanceName: string, The instance of the execution system to operate against. A server may
266support multiple instances of the execution system (with their own workers,
267storage, caches, etc.). The server MAY require use of this field to select
268between them in an implementation-defined fashion, otherwise it can be
269omitted. (required)
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]270 body: object, The request body.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]271 The object takes the form of:
272
273{ # A request message for
274 # ContentAddressableStorage.BatchUpdateBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]275 &quot;requests&quot;: [ # The individual upload requests.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]276 { # A request corresponding to a single blob that the client wants to upload.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]277 &quot;data&quot;: &quot;A String&quot;, # The raw binary data.
278 &quot;digest&quot;: { # 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`.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]279 # and its hash. The hash algorithm to use is defined by the server.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]280 #
281 # The size is considered to be an integral part of the digest and cannot be
282 # separated. That is, even if the `hash` field is correctly specified but
283 # `size_bytes` is not, the server MUST reject the request.
284 #
285 # The reason for including the size in the digest is as follows: in a great
286 # many cases, the server needs to know the size of the blob it is about to work
287 # with prior to starting an operation with it, such as flattening Merkle tree
288 # structures or streaming it to a worker. Technically, the server could
289 # implement a separate metadata store, but this results in a significantly more
290 # complicated implementation as opposed to having the client specify the size
291 # up-front (or storing the size along with the digest in every message where
292 # digests are embedded). This does mean that the API leaks some implementation
293 # details of (what we consider to be) a reasonable server implementation, but
294 # we consider this to be a worthwhile tradeoff.
295 #
296 # When a `Digest` is used to refer to a proto message, it always refers to the
297 # message in binary encoded form. To ensure consistent hashing, clients and
298 # servers MUST ensure that they serialize messages according to the following
299 # rules, even if there are alternate valid encodings for the same message:
300 #
301 # * Fields are serialized in tag order.
302 # * There are no unknown fields.
303 # * There are no duplicate fields.
304 # * Fields are serialized according to the default semantics for their type.
305 #
306 # Most protocol buffer implementations will always follow these rules when
307 # serializing, but care should be taken to avoid shortcuts. For instance,
308 # concatenating two messages to merge them may produce duplicate fields.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]309 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
310 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]311 # exactly 64 characters long.
312 },
313 },
314 ],
315 }
316
317 x__xgafv: string, V1 error format.
318 Allowed values
319 1 - v1 error format
320 2 - v2 error format
321
322Returns:
323 An object of the form:
324
325 { # A response message for
326 # ContentAddressableStorage.BatchUpdateBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]327 &quot;responses&quot;: [ # The responses to the requests.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]328 { # A response corresponding to a single blob that the client tried to upload.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]329 &quot;digest&quot;: { # A content digest. A digest for a given blob consists of the size of the blob # The blob digest to which this response corresponds.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]330 # and its hash. The hash algorithm to use is defined by the server.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]331 #
332 # The size is considered to be an integral part of the digest and cannot be
333 # separated. That is, even if the `hash` field is correctly specified but
334 # `size_bytes` is not, the server MUST reject the request.
335 #
336 # The reason for including the size in the digest is as follows: in a great
337 # many cases, the server needs to know the size of the blob it is about to work
338 # with prior to starting an operation with it, such as flattening Merkle tree
339 # structures or streaming it to a worker. Technically, the server could
340 # implement a separate metadata store, but this results in a significantly more
341 # complicated implementation as opposed to having the client specify the size
342 # up-front (or storing the size along with the digest in every message where
343 # digests are embedded). This does mean that the API leaks some implementation
344 # details of (what we consider to be) a reasonable server implementation, but
345 # we consider this to be a worthwhile tradeoff.
346 #
347 # When a `Digest` is used to refer to a proto message, it always refers to the
348 # message in binary encoded form. To ensure consistent hashing, clients and
349 # servers MUST ensure that they serialize messages according to the following
350 # rules, even if there are alternate valid encodings for the same message:
351 #
352 # * Fields are serialized in tag order.
353 # * There are no unknown fields.
354 # * There are no duplicate fields.
355 # * Fields are serialized according to the default semantics for their type.
356 #
357 # Most protocol buffer implementations will always follow these rules when
358 # serializing, but care should be taken to avoid shortcuts. For instance,
359 # concatenating two messages to merge them may produce duplicate fields.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]360 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
361 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]362 # exactly 64 characters long.
363 },
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]364 &quot;status&quot;: { # The `Status` type defines a logical error model that is suitable for # The result of attempting to upload that blob.
365 # different programming environments, including REST APIs and RPC APIs. It is
366 # used by [gRPC](https://github.com/grpc). Each `Status` message contains
367 # three pieces of data: error code, error message, and error details.
368 #
369 # You can find out more about this error model and how to work with it in the
370 # [API Design Guide](https://cloud.google.com/apis/design/errors).
371 &quot;code&quot;: 42, # The status code, which should be an enum value of google.rpc.Code.
372 &quot;message&quot;: &quot;A String&quot;, # A developer-facing error message, which should be in English. Any
373 # user-facing error message should be localized and sent in the
374 # google.rpc.Status.details field, or localized by the client.
375 &quot;details&quot;: [ # A list of messages that carry the error details. There is a common set of
376 # message types for APIs to use.
377 {
378 &quot;a_key&quot;: &quot;&quot;, # Properties of the object. Contains field @type with type URL.
379 },
380 ],
381 },
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]382 },
383 ],
384 }</pre>
385</div>
386
387<div class="method">
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]388 <code class="details" id="findMissing">findMissing(instanceName, body=None, x__xgafv=None)</code>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]389 <pre>Determine if blobs are present in the CAS.
390
391Clients can use this API before uploading blobs to determine which ones are
392already present in the CAS and do not need to be uploaded again.
393
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]394Servers SHOULD increase the TTLs of the referenced blobs if necessary and
395applicable.
396
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]397There are no method-specific errors.
398
399Args:
400 instanceName: string, The instance of the execution system to operate against. A server may
401support multiple instances of the execution system (with their own workers,
402storage, caches, etc.). The server MAY require use of this field to select
403between them in an implementation-defined fashion, otherwise it can be
404omitted. (required)
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]405 body: object, The request body.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]406 The object takes the form of:
407
408{ # A request message for
409 # ContentAddressableStorage.FindMissingBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]410 &quot;blobDigests&quot;: [ # A list of the blobs to check.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]411 { # A content digest. A digest for a given blob consists of the size of the blob
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]412 # and its hash. The hash algorithm to use is defined by the server.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]413 #
414 # The size is considered to be an integral part of the digest and cannot be
415 # separated. That is, even if the `hash` field is correctly specified but
416 # `size_bytes` is not, the server MUST reject the request.
417 #
418 # The reason for including the size in the digest is as follows: in a great
419 # many cases, the server needs to know the size of the blob it is about to work
420 # with prior to starting an operation with it, such as flattening Merkle tree
421 # structures or streaming it to a worker. Technically, the server could
422 # implement a separate metadata store, but this results in a significantly more
423 # complicated implementation as opposed to having the client specify the size
424 # up-front (or storing the size along with the digest in every message where
425 # digests are embedded). This does mean that the API leaks some implementation
426 # details of (what we consider to be) a reasonable server implementation, but
427 # we consider this to be a worthwhile tradeoff.
428 #
429 # When a `Digest` is used to refer to a proto message, it always refers to the
430 # message in binary encoded form. To ensure consistent hashing, clients and
431 # servers MUST ensure that they serialize messages according to the following
432 # rules, even if there are alternate valid encodings for the same message:
433 #
434 # * Fields are serialized in tag order.
435 # * There are no unknown fields.
436 # * There are no duplicate fields.
437 # * Fields are serialized according to the default semantics for their type.
438 #
439 # Most protocol buffer implementations will always follow these rules when
440 # serializing, but care should be taken to avoid shortcuts. For instance,
441 # concatenating two messages to merge them may produce duplicate fields.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]442 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
443 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]444 # exactly 64 characters long.
445 },
446 ],
447 }
448
449 x__xgafv: string, V1 error format.
450 Allowed values
451 1 - v1 error format
452 2 - v2 error format
453
454Returns:
455 An object of the form:
456
457 { # A response message for
458 # ContentAddressableStorage.FindMissingBlobs.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]459 &quot;missingBlobDigests&quot;: [ # A list of the blobs requested *not* present in the storage.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]460 { # A content digest. A digest for a given blob consists of the size of the blob
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]461 # and its hash. The hash algorithm to use is defined by the server.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]462 #
463 # The size is considered to be an integral part of the digest and cannot be
464 # separated. That is, even if the `hash` field is correctly specified but
465 # `size_bytes` is not, the server MUST reject the request.
466 #
467 # The reason for including the size in the digest is as follows: in a great
468 # many cases, the server needs to know the size of the blob it is about to work
469 # with prior to starting an operation with it, such as flattening Merkle tree
470 # structures or streaming it to a worker. Technically, the server could
471 # implement a separate metadata store, but this results in a significantly more
472 # complicated implementation as opposed to having the client specify the size
473 # up-front (or storing the size along with the digest in every message where
474 # digests are embedded). This does mean that the API leaks some implementation
475 # details of (what we consider to be) a reasonable server implementation, but
476 # we consider this to be a worthwhile tradeoff.
477 #
478 # When a `Digest` is used to refer to a proto message, it always refers to the
479 # message in binary encoded form. To ensure consistent hashing, clients and
480 # servers MUST ensure that they serialize messages according to the following
481 # rules, even if there are alternate valid encodings for the same message:
482 #
483 # * Fields are serialized in tag order.
484 # * There are no unknown fields.
485 # * There are no duplicate fields.
486 # * Fields are serialized according to the default semantics for their type.
487 #
488 # Most protocol buffer implementations will always follow these rules when
489 # serializing, but care should be taken to avoid shortcuts. For instance,
490 # concatenating two messages to merge them may produce duplicate fields.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]491 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
492 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]493 # exactly 64 characters long.
494 },
495 ],
496 }</pre>
497</div>
498
499<div class="method">
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]500 <code class="details" id="getTree">getTree(instanceName, hash, sizeBytes, pageToken=None, pageSize=None, x__xgafv=None)</code>
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]501 <pre>Fetch the entire directory tree rooted at a node.
502
503This request must be targeted at a
504Directory stored in the
505ContentAddressableStorage
506(CAS). The server will enumerate the `Directory` tree recursively and
507return every node descended from the root.
508
509The GetTreeRequest.page_token parameter can be used to skip ahead in
510the stream (e.g. when retrying a partially completed and aborted request),
511by setting it to a value taken from GetTreeResponse.next_page_token of the
512last successfully processed GetTreeResponse).
513
514The exact traversal order is unspecified and, unless retrieving subsequent
515pages from an earlier request, is not guaranteed to be stable across
516multiple invocations of `GetTree`.
517
518If part of the tree is missing from the CAS, the server will return the
519portion present and omit the rest.
520
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]521Errors:
522
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]523* `NOT_FOUND`: The requested tree root is not present in the CAS.
524
525Args:
526 instanceName: string, The instance of the execution system to operate against. A server may
527support multiple instances of the execution system (with their own workers,
528storage, caches, etc.). The server MAY require use of this field to select
529between them in an implementation-defined fashion, otherwise it can be
530omitted. (required)
531 hash: string, The hash. In the case of SHA-256, it will always be a lowercase hex string
532exactly 64 characters long. (required)
533 sizeBytes: string, The size of the blob, in bytes. (required)
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]534 pageToken: string, A page token, which must be a value received in a previous
535GetTreeResponse.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]536If present, the server will use that token as an offset, returning only
537that page and the ones that succeed it.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]538 pageSize: integer, A maximum page size to request. If present, the server will request no more
539than this many items. Regardless of whether a page size is specified, the
540server may place its own limit on the number of items to be returned and
541require the client to retrieve more items using a subsequent request.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]542 x__xgafv: string, V1 error format.
543 Allowed values
544 1 - v1 error format
545 2 - v2 error format
546
547Returns:
548 An object of the form:
549
550 { # A response message for
551 # ContentAddressableStorage.GetTree.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]552 &quot;directories&quot;: [ # The directories descended from the requested root.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]553 { # A `Directory` represents a directory node in a file tree, containing zero or
554 # more children FileNodes,
555 # DirectoryNodes and
556 # SymlinkNodes.
557 # Each `Node` contains its name in the directory, either the digest of its
558 # content (either a file blob or a `Directory` proto) or a symlink target, as
559 # well as possibly some metadata about the file or directory.
560 #
561 # In order to ensure that two equivalent directory trees hash to the same
562 # value, the following restrictions MUST be obeyed when constructing a
563 # a `Directory`:
564 #
565 # * Every child in the directory must have a path of exactly one segment.
566 # Multiple levels of directory hierarchy may not be collapsed.
567 # * Each child in the directory must have a unique path segment (file name).
568 # Note that while the API itself is case-sensitive, the environment where
569 # the Action is executed may or may not be case-sensitive. That is, it is
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]570 # legal to call the API with a Directory that has both &quot;Foo&quot; and &quot;foo&quot; as
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]571 # children, but the Action may be rejected by the remote system upon
572 # execution.
573 # * The files, directories and symlinks in the directory must each be sorted
574 # in lexicographical order by path. The path strings must be sorted by code
575 # point, equivalently, by UTF-8 bytes.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]576 # * The NodeProperties of files,
577 # directories, and symlinks must be sorted in lexicographical order by
578 # property name.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]579 #
580 # A `Directory` that obeys the restrictions is said to be in canonical form.
581 #
582 # As an example, the following could be used for a file named `bar` and a
583 # directory named `foo` with an executable file named `baz` (hashes shortened
584 # for readability):
585 #
586 # ```json
587 # // (Directory proto)
588 # {
589 # files: [
590 # {
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]591 # name: &quot;bar&quot;,
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]592 # digest: {
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]593 # hash: &quot;4a73bc9d03...&quot;,
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]594 # size: 65534
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]595 # },
596 # node_properties: [
597 # {
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]598 # &quot;name&quot;: &quot;MTime&quot;,
599 # &quot;value&quot;: &quot;2017-01-15T01:30:15.01Z&quot;
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]600 # }
601 # ]
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]602 # }
603 # ],
604 # directories: [
605 # {
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]606 # name: &quot;foo&quot;,
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]607 # digest: {
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]608 # hash: &quot;4cf2eda940...&quot;,
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]609 # size: 43
610 # }
611 # }
612 # ]
613 # }
614 #
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]615 # // (Directory proto with hash &quot;4cf2eda940...&quot; and size 43)
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]616 # {
617 # files: [
618 # {
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]619 # name: &quot;baz&quot;,
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]620 # digest: {
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]621 # hash: &quot;b2c941073e...&quot;,
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]622 # size: 1294,
623 # },
624 # is_executable: true
625 # }
626 # ]
627 # }
628 # ```
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]629 &quot;files&quot;: [ # The files in the directory.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]630 { # A `FileNode` represents a single file and associated metadata.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]631 &quot;nodeProperties&quot;: [ # The node properties of the FileNode.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]632 { # A single property for FileNodes,
633 # DirectoryNodes, and
634 # SymlinkNodes. The server is
635 # responsible for specifying the property `name`s that it accepts. If
636 # permitted by the server, the same `name` may occur multiple times.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]637 &quot;value&quot;: &quot;A String&quot;, # The property value.
638 &quot;name&quot;: &quot;A String&quot;, # The property name.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]639 },
640 ],
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]641 &quot;name&quot;: &quot;A String&quot;, # The name of the file.
642 &quot;digest&quot;: { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the file&#x27;s content.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]643 # and its hash. The hash algorithm to use is defined by the server.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]644 #
645 # The size is considered to be an integral part of the digest and cannot be
646 # separated. That is, even if the `hash` field is correctly specified but
647 # `size_bytes` is not, the server MUST reject the request.
648 #
649 # The reason for including the size in the digest is as follows: in a great
650 # many cases, the server needs to know the size of the blob it is about to work
651 # with prior to starting an operation with it, such as flattening Merkle tree
652 # structures or streaming it to a worker. Technically, the server could
653 # implement a separate metadata store, but this results in a significantly more
654 # complicated implementation as opposed to having the client specify the size
655 # up-front (or storing the size along with the digest in every message where
656 # digests are embedded). This does mean that the API leaks some implementation
657 # details of (what we consider to be) a reasonable server implementation, but
658 # we consider this to be a worthwhile tradeoff.
659 #
660 # When a `Digest` is used to refer to a proto message, it always refers to the
661 # message in binary encoded form. To ensure consistent hashing, clients and
662 # servers MUST ensure that they serialize messages according to the following
663 # rules, even if there are alternate valid encodings for the same message:
664 #
665 # * Fields are serialized in tag order.
666 # * There are no unknown fields.
667 # * There are no duplicate fields.
668 # * Fields are serialized according to the default semantics for their type.
669 #
670 # Most protocol buffer implementations will always follow these rules when
671 # serializing, but care should be taken to avoid shortcuts. For instance,
672 # concatenating two messages to merge them may produce duplicate fields.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]673 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
674 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]675 # exactly 64 characters long.
676 },
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]677 &quot;isExecutable&quot;: True or False, # True if file is executable, false otherwise.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]678 },
679 ],
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]680 &quot;directories&quot;: [ # The subdirectories in the directory.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]681 { # A `DirectoryNode` represents a child of a
682 # Directory which is itself
683 # a `Directory` and its associated metadata.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]684 &quot;name&quot;: &quot;A String&quot;, # The name of the directory.
685 &quot;digest&quot;: { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]686 # Directory object
687 # represented. See Digest
688 # for information about how to take the digest of a proto message.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]689 # and its hash. The hash algorithm to use is defined by the server.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]690 #
691 # The size is considered to be an integral part of the digest and cannot be
692 # separated. That is, even if the `hash` field is correctly specified but
693 # `size_bytes` is not, the server MUST reject the request.
694 #
695 # The reason for including the size in the digest is as follows: in a great
696 # many cases, the server needs to know the size of the blob it is about to work
697 # with prior to starting an operation with it, such as flattening Merkle tree
698 # structures or streaming it to a worker. Technically, the server could
699 # implement a separate metadata store, but this results in a significantly more
700 # complicated implementation as opposed to having the client specify the size
701 # up-front (or storing the size along with the digest in every message where
702 # digests are embedded). This does mean that the API leaks some implementation
703 # details of (what we consider to be) a reasonable server implementation, but
704 # we consider this to be a worthwhile tradeoff.
705 #
706 # When a `Digest` is used to refer to a proto message, it always refers to the
707 # message in binary encoded form. To ensure consistent hashing, clients and
708 # servers MUST ensure that they serialize messages according to the following
709 # rules, even if there are alternate valid encodings for the same message:
710 #
711 # * Fields are serialized in tag order.
712 # * There are no unknown fields.
713 # * There are no duplicate fields.
714 # * Fields are serialized according to the default semantics for their type.
715 #
716 # Most protocol buffer implementations will always follow these rules when
717 # serializing, but care should be taken to avoid shortcuts. For instance,
718 # concatenating two messages to merge them may produce duplicate fields.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]719 &quot;sizeBytes&quot;: &quot;A String&quot;, # The size of the blob, in bytes.
720 &quot;hash&quot;: &quot;A String&quot;, # The hash. In the case of SHA-256, it will always be a lowercase hex string
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]721 # exactly 64 characters long.
722 },
723 },
724 ],
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]725 &quot;nodeProperties&quot;: [ # The node properties of the Directory.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]726 { # A single property for FileNodes,
727 # DirectoryNodes, and
728 # SymlinkNodes. The server is
729 # responsible for specifying the property `name`s that it accepts. If
730 # permitted by the server, the same `name` may occur multiple times.
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]731 &quot;value&quot;: &quot;A String&quot;, # The property value.
732 &quot;name&quot;: &quot;A String&quot;, # The property name.
733 },
734 ],
735 &quot;symlinks&quot;: [ # The symlinks in the directory.
736 { # A `SymlinkNode` represents a symbolic link.
737 &quot;nodeProperties&quot;: [ # The node properties of the SymlinkNode.
738 { # A single property for FileNodes,
739 # DirectoryNodes, and
740 # SymlinkNodes. The server is
741 # responsible for specifying the property `name`s that it accepts. If
742 # permitted by the server, the same `name` may occur multiple times.
743 &quot;value&quot;: &quot;A String&quot;, # The property value.
744 &quot;name&quot;: &quot;A String&quot;, # The property name.
745 },
746 ],
747 &quot;name&quot;: &quot;A String&quot;, # The name of the symlink.
748 &quot;target&quot;: &quot;A String&quot;, # The target path of the symlink. The path separator is a forward slash `/`.
749 # The target path can be relative to the parent directory of the symlink or
750 # it can be an absolute path starting with `/`. Support for absolute paths
751 # can be checked using the Capabilities
752 # API. The canonical form forbids the substrings `/./` and `//` in the target
753 # path. `..` components are allowed anywhere in the target path.
Dan O'Mearadd494642020-05-01 07:42:23 -0700[diff] [blame]754 },
755 ],
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]756 },
757 ],
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]758 &quot;nextPageToken&quot;: &quot;A String&quot;, # If present, signifies that there are more results which the client can
759 # retrieve by passing this as the page_token in a subsequent
760 # request.
761 # If empty, signifies that this is the last page of results.
Bu Sun Kim715bd7f2019-06-14 16:50:42 -0700[diff] [blame]762 }</pre>
763</div>
764
765<div class="method">
766 <code class="details" id="getTree_next">getTree_next(previous_request, previous_response)</code>
767 <pre>Retrieves the next page of results.
768
769Args:
770 previous_request: The request for the previous page. (required)
771 previous_response: The response from the request for the previous page. (required)
772
773Returns:
Bu Sun Kim65020912020-05-20 12:08:20 -0700[diff] [blame^]774 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]775 page. Returns None if there are no more items in the collection.
776 </pre>
777</div>
778
779</body></html>