| <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> |