Lines Matching full:the
88 Implementations SHOULD ensure that any blobs referenced from the
90 are available at the time of returning the
92 for some period of time afterwards. The TTLs of the referenced blobs SHOULD be increased
97 * `NOT_FOUND`: The requested `ActionResult` is not in the cache.
100 instanceName: string, The instance of the execution system to operate against. A server may
101 support multiple instances of the execution system (with their own workers,
102 storage, caches, etc.). The server MAY require use of this field to select
105 hash: string, The hash. In the case of SHA-256, it will always be a lowercase hex string
107 sizeBytes: string, The size of the blob, in bytes. (required)
108 inlineStdout: boolean, A hint to the server to request inlining stdout in the
110 inlineOutputFiles: string, A hint to the server to inline the contents of the listed output files.
111 Each path needs to exactly match one path in `output_files` in the
113 inlineStderr: boolean, A hint to the server to request inlining stderr in the
121 An object of the form:
123 { # An ActionResult represents the result of an
125 …utedActionMetadata contains details about a completed execution. # The details of the execution th…
126 … "outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
127 …"workerCompletedTimestamp": "A String", # When the worker completed the action, including all stag…
128 "queuedTimestamp": "A String", # When was the action added to the queue.
129 "worker": "A String", # The name of the worker which ran the execution.
130 … "executionStartTimestamp": "A String", # When the worker started executing the action command.
131 "inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
132 "workerStartTimestamp": "A String", # When the worker received the action.
133 … "outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
134 …"executionCompletedTimestamp": "A String", # When the worker completed executing the action comman…
135 … "inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
137 …"outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. T…
139 # outside of the working directory, if the server supports
141 # For each output file requested in the `output_files` field of the Action,
142 # if the corresponding file existed after
143 # the action completed, a single entry will be present either in this field,
144 # or in the `output_files` field, if the file was not a symbolic link.
146 # If an output symbolic link of the same name was found, but its target
147 # type was not a regular file, the server will return a FAILED_PRECONDITION.
148 # If the action does not produce the requested output, then that output
149 # will be omitted from the list. The server is free to arrange the output
150 # list as desired; clients MUST NOT assume that the output list is sorted.
156 …"path": "A String", # The full path of the symlink relative to the working directory, including the
157 # filename. The path separator is a forward slash `/`. Since this is a
159 … "target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.
160 # The target path can be relative to the parent directory of the symlink or
162 # can be checked using the Capabilities
163 # API. The canonical form forbids the substrings `/./` and `//` in the target
164 # path. `..` components are allowed anywhere in the target path.
167 …digest for a given blob consists of the size of the blob # The digest for a blob containing the st…
168 # can be retrieved from the
170 # and its hash. The hash algorithm to use is defined by the server, but servers
173 # The size is considered to be an integral part of the digest and cannot be
174 # separated. That is, even if the `hash` field is correctly specified but
175 # `size_bytes` is not, the server MUST reject the request.
177 # The reason for including the size in the digest is as follows: in a great
178 # many cases, the server needs to know the size of the blob it is about to work
180 # structures or streaming it to a worker. Technically, the server could
182 # complicated implementation as opposed to having the client specify the size
183 # up-front (or storing the size along with the digest in every message where
184 # digests are embedded). This does mean that the API leaks some implementation
188 # When a `Digest` is used to refer to a proto message, it always refers to the
190 # servers MUST ensure that they serialize messages according to the following
191 # rules, even if there are alternate valid encodings for the same message:
196 # * Fields are serialized according to the default semantics for their type.
201 "sizeBytes": "A String", # The size of the blob, in bytes.
202 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
205 … "stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline
206 # stdout unless requested by the client in the
208 # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
209 # would cause the response to exceed message size limits.
210 … "stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline
211 # stderr unless requested by the client in the
213 # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
214 # would cause the response to exceed message size limits.
215 …igest for a given blob consists of the size of the blob # The digest for a blob containing the sta…
216 # can be retrieved from the
218 # and its hash. The hash algorithm to use is defined by the server, but servers
221 # The size is considered to be an integral part of the digest and cannot be
222 # separated. That is, even if the `hash` field is correctly specified but
223 # `size_bytes` is not, the server MUST reject the request.
225 # The reason for including the size in the digest is as follows: in a great
226 # many cases, the server needs to know the size of the blob it is about to work
228 # structures or streaming it to a worker. Technically, the server could
230 # complicated implementation as opposed to having the client specify the size
231 # up-front (or storing the size along with the digest in every message where
232 # digests are embedded). This does mean that the API leaks some implementation
236 # When a `Digest` is used to refer to a proto message, it always refers to the
238 # servers MUST ensure that they serialize messages according to the following
239 # rules, even if there are alternate valid encodings for the same message:
244 # * Fields are serialized according to the default semantics for their type.
249 "sizeBytes": "A String", # The size of the blob, in bytes.
250 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
253 "outputFiles": [ # The output files of the action. For each output file requested in the
254 # `output_files` field of the Action, if the corresponding file existed after
255 # the action completed, a single entry will be present either in this field,
256 # or the `output_file_symlinks` field if the file was a symbolic link to
259 # If an output of the same name was found, but was a directory rather
260 # than a regular file, the server will return a FAILED_PRECONDITION.
261 # If the action does not produce the requested output, then that output
262 # will be omitted from the list. The server is free to arrange the output
263 # list as desired; clients MUST NOT assume that the output list is sorted.
268 … "path": "A String", # The full path of the file relative to the working directory, including the
269 # filename. The path separator is a forward slash `/`. Since this is a
272 …"contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NO…
273 # file contents unless requested by the client in the
275 # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
276 # would cause the response to exceed message size limits.
277 …A content digest. A digest for a given blob consists of the size of the blob # The digest of the f…
278 # and its hash. The hash algorithm to use is defined by the server, but servers
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.
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
288 # structures or streaming it to a worker. Technically, the server could
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
296 # When a `Digest` is used to refer to a proto message, it always refers to the
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:
304 # * Fields are serialized according to the default semantics for their type.
309 "sizeBytes": "A String", # The size of the blob, in bytes.
310 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
315 …"outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to oth…
317 # directories, or even absolute paths outside of the working directory,
318 # if the server supports
320 # For each output directory requested in the `output_directories` field of
321 # the Action, if the directory existed after the action completed, a
322 # single entry will be present either in this field, or in the
323 # `output_directories` field, if the directory was not a symbolic link.
325 # If an output of the same name was found, but was a symbolic link to a file
326 # instead of a directory, the server will return a FAILED_PRECONDITION.
327 # If the action does not produce the requested output, then that output
328 # will be omitted from the list. The server is free to arrange the output
329 # list as desired; clients MUST NOT assume that the output list is sorted.
335 …"path": "A String", # The full path of the symlink relative to the working directory, including the
336 # filename. The path separator is a forward slash `/`. Since this is a
338 … "target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.
339 # The target path can be relative to the parent directory of the symlink or
341 # can be checked using the Capabilities
342 # API. The canonical form forbids the substrings `/./` and `//` in the target
343 # path. `..` components are allowed anywhere in the target path.
346 … "outputDirectories": [ # The output directories of the action. For each output directory requested
347 # in the `output_directories` field of the Action, if the corresponding
348 # directory existed after the action completed, a single entry will be
349 # present in the output list, which will contain the digest of a
350 # Tree message containing the
351 # directory tree, and the path equal exactly to the corresponding Action
354 # As an example, suppose the Action had an output directory `a/b/dir` and the
355 # execution produced the following contents in `a/b/dir`: a file named `bar`
405 # If an output of the same name was found, but was not a directory, the
407 { # An `OutputDirectory` is the output in an `ActionResult` corresponding to a
409 … "path": "A String", # The full path of the directory relative to the working directory. The path
411 # NOT begin with a leading forward slash. The empty string value is allowed,
412 # and it denotes the entire working directory.
413 …A content digest. A digest for a given blob consists of the size of the blob # The digest of the e…
414 # Tree proto containing the
416 # and its hash. The hash algorithm to use is defined by the server, but servers
419 # The size is considered to be an integral part of the digest and cannot be
420 # separated. That is, even if the `hash` field is correctly specified but
421 # `size_bytes` is not, the server MUST reject the request.
423 # The reason for including the size in the digest is as follows: in a great
424 # many cases, the server needs to know the size of the blob it is about to work
426 # structures or streaming it to a worker. Technically, the server could
428 # complicated implementation as opposed to having the client specify the size
429 # up-front (or storing the size along with the digest in every message where
430 # digests are embedded). This does mean that the API leaks some implementation
434 # When a `Digest` is used to refer to a proto message, it always refers to the
436 # servers MUST ensure that they serialize messages according to the following
437 # rules, even if there are alternate valid encodings for the same message:
442 # * Fields are serialized according to the default semantics for their type.
447 "sizeBytes": "A String", # The size of the blob, in bytes.
448 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
453 "exitCode": 42, # The exit code of the command.
461 In order to allow the server to perform access control based on the type of
462 action, and to assist with client debugging, the client MUST first upload
463 the Action that produced the
465 Command, into the
471 * `FAILED_PRECONDITION`: One or more errors occurred in updating the
473 * `RESOURCE_EXHAUSTED`: There is insufficient storage space to add the
474 entry to the cache.
477 instanceName: string, The instance of the execution system to operate against. A server may
478 support multiple instances of the execution system (with their own workers,
479 storage, caches, etc.). The server MAY require use of this field to select
482 hash: string, The hash. In the case of SHA-256, it will always be a lowercase hex string
484 sizeBytes: string, The size of the blob, in bytes. (required)
485 body: object, The request body. (required)
486 The object takes the form of:
488 { # An ActionResult represents the result of an
490 …utedActionMetadata contains details about a completed execution. # The details of the execution th…
491 "outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
492 …"workerCompletedTimestamp": "A String", # When the worker completed the action, including all stag…
493 "queuedTimestamp": "A String", # When was the action added to the queue.
494 "worker": "A String", # The name of the worker which ran the execution.
495 "executionStartTimestamp": "A String", # When the worker started executing the action command.
496 "inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
497 "workerStartTimestamp": "A String", # When the worker received the action.
498 … "outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
499 …"executionCompletedTimestamp": "A String", # When the worker completed executing the action comman…
500 "inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
502 …"outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. T…
504 # outside of the working directory, if the server supports
506 # For each output file requested in the `output_files` field of the Action,
507 # if the corresponding file existed after
508 # the action completed, a single entry will be present either in this field,
509 # or in the `output_files` field, if the file was not a symbolic link.
511 # If an output symbolic link of the same name was found, but its target
512 # type was not a regular file, the server will return a FAILED_PRECONDITION.
513 # If the action does not produce the requested output, then that output
514 # will be omitted from the list. The server is free to arrange the output
515 # list as desired; clients MUST NOT assume that the output list is sorted.
521 …"path": "A String", # The full path of the symlink relative to the working directory, including the
522 # filename. The path separator is a forward slash `/`. Since this is a
524 … "target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.
525 # The target path can be relative to the parent directory of the symlink or
527 # can be checked using the Capabilities
528 # API. The canonical form forbids the substrings `/./` and `//` in the target
529 # path. `..` components are allowed anywhere in the target path.
532 …digest for a given blob consists of the size of the blob # The digest for a blob containing the st…
533 # can be retrieved from the
535 # and its hash. The hash algorithm to use is defined by the server, but servers
538 # The size is considered to be an integral part of the digest and cannot be
539 # separated. That is, even if the `hash` field is correctly specified but
540 # `size_bytes` is not, the server MUST reject the request.
542 # The reason for including the size in the digest is as follows: in a great
543 # many cases, the server needs to know the size of the blob it is about to work
545 # structures or streaming it to a worker. Technically, the server could
547 # complicated implementation as opposed to having the client specify the size
548 # up-front (or storing the size along with the digest in every message where
549 # digests are embedded). This does mean that the API leaks some implementation
553 # When a `Digest` is used to refer to a proto message, it always refers to the
555 # servers MUST ensure that they serialize messages according to the following
556 # rules, even if there are alternate valid encodings for the same message:
561 # * Fields are serialized according to the default semantics for their type.
566 "sizeBytes": "A String", # The size of the blob, in bytes.
567 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
570 … "stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline
571 # stdout unless requested by the client in the
573 # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
574 # would cause the response to exceed message size limits.
575 "stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline
576 # stderr unless requested by the client in the
578 # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
579 # would cause the response to exceed message size limits.
580 …igest for a given blob consists of the size of the blob # The digest for a blob containing the sta…
581 # can be retrieved from the
583 # and its hash. The hash algorithm to use is defined by the server, but servers
586 # The size is considered to be an integral part of the digest and cannot be
587 # separated. That is, even if the `hash` field is correctly specified but
588 # `size_bytes` is not, the server MUST reject the request.
590 # The reason for including the size in the digest is as follows: in a great
591 # many cases, the server needs to know the size of the blob it is about to work
593 # structures or streaming it to a worker. Technically, the server could
595 # complicated implementation as opposed to having the client specify the size
596 # up-front (or storing the size along with the digest in every message where
597 # digests are embedded). This does mean that the API leaks some implementation
601 # When a `Digest` is used to refer to a proto message, it always refers to the
603 # servers MUST ensure that they serialize messages according to the following
604 # rules, even if there are alternate valid encodings for the same message:
609 # * Fields are serialized according to the default semantics for their type.
614 "sizeBytes": "A String", # The size of the blob, in bytes.
615 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
618 "outputFiles": [ # The output files of the action. For each output file requested in the
619 # `output_files` field of the Action, if the corresponding file existed after
620 # the action completed, a single entry will be present either in this field,
621 # or the `output_file_symlinks` field if the file was a symbolic link to
624 # If an output of the same name was found, but was a directory rather
625 # than a regular file, the server will return a FAILED_PRECONDITION.
626 # If the action does not produce the requested output, then that output
627 # will be omitted from the list. The server is free to arrange the output
628 # list as desired; clients MUST NOT assume that the output list is sorted.
633 … "path": "A String", # The full path of the file relative to the working directory, including the
634 # filename. The path separator is a forward slash `/`. Since this is a
637 …"contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NO…
638 # file contents unless requested by the client in the
640 # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
641 # would cause the response to exceed message size limits.
642 …A content digest. A digest for a given blob consists of the size of the blob # The digest of the f…
643 # and its hash. The hash algorithm to use is defined by the server, but servers
646 # The size is considered to be an integral part of the digest and cannot be
647 # separated. That is, even if the `hash` field is correctly specified but
648 # `size_bytes` is not, the server MUST reject the request.
650 # The reason for including the size in the digest is as follows: in a great
651 # many cases, the server needs to know the size of the blob it is about to work
653 # structures or streaming it to a worker. Technically, the server could
655 # complicated implementation as opposed to having the client specify the size
656 # up-front (or storing the size along with the digest in every message where
657 # digests are embedded). This does mean that the API leaks some implementation
661 # When a `Digest` is used to refer to a proto message, it always refers to the
663 # servers MUST ensure that they serialize messages according to the following
664 # rules, even if there are alternate valid encodings for the same message:
669 # * Fields are serialized according to the default semantics for their type.
674 "sizeBytes": "A String", # The size of the blob, in bytes.
675 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
680 …"outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to oth…
682 # directories, or even absolute paths outside of the working directory,
683 # if the server supports
685 # For each output directory requested in the `output_directories` field of
686 # the Action, if the directory existed after the action completed, a
687 # single entry will be present either in this field, or in the
688 # `output_directories` field, if the directory was not a symbolic link.
690 # If an output of the same name was found, but was a symbolic link to a file
691 # instead of a directory, the server will return a FAILED_PRECONDITION.
692 # If the action does not produce the requested output, then that output
693 # will be omitted from the list. The server is free to arrange the output
694 # list as desired; clients MUST NOT assume that the output list is sorted.
700 …"path": "A String", # The full path of the symlink relative to the working directory, including the
701 # filename. The path separator is a forward slash `/`. Since this is a
703 … "target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.
704 # The target path can be relative to the parent directory of the symlink or
706 # can be checked using the Capabilities
707 # API. The canonical form forbids the substrings `/./` and `//` in the target
708 # path. `..` components are allowed anywhere in the target path.
711 … "outputDirectories": [ # The output directories of the action. For each output directory requested
712 # in the `output_directories` field of the Action, if the corresponding
713 # directory existed after the action completed, a single entry will be
714 # present in the output list, which will contain the digest of a
715 # Tree message containing the
716 # directory tree, and the path equal exactly to the corresponding Action
719 # As an example, suppose the Action had an output directory `a/b/dir` and the
720 # execution produced the following contents in `a/b/dir`: a file named `bar`
770 # If an output of the same name was found, but was not a directory, the
772 { # An `OutputDirectory` is the output in an `ActionResult` corresponding to a
774 … "path": "A String", # The full path of the directory relative to the working directory. The path
776 # NOT begin with a leading forward slash. The empty string value is allowed,
777 # and it denotes the entire working directory.
778 …A content digest. A digest for a given blob consists of the size of the blob # The digest of the e…
779 # Tree proto containing the
781 # and its hash. The hash algorithm to use is defined by the server, but servers
784 # The size is considered to be an integral part of the digest and cannot be
785 # separated. That is, even if the `hash` field is correctly specified but
786 # `size_bytes` is not, the server MUST reject the request.
788 # The reason for including the size in the digest is as follows: in a great
789 # many cases, the server needs to know the size of the blob it is about to work
791 # structures or streaming it to a worker. Technically, the server could
793 # complicated implementation as opposed to having the client specify the size
794 # up-front (or storing the size along with the digest in every message where
795 # digests are embedded). This does mean that the API leaks some implementation
799 # When a `Digest` is used to refer to a proto message, it always refers to the
801 # servers MUST ensure that they serialize messages according to the following
802 # rules, even if there are alternate valid encodings for the same message:
807 # * Fields are serialized according to the default semantics for their type.
812 "sizeBytes": "A String", # The size of the blob, in bytes.
813 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
818 "exitCode": 42, # The exit code of the command.
821 …resultsCachePolicy_priority: integer, The priority (relative importance) of this content in the ov…
823 but the interpretation of a given value is server-dependent. A priority of
824 0 means a *default* value, decided by the server.
826 The particular semantics of this field is up to the server. In particular,
835 An object of the form:
837 { # An ActionResult represents the result of an
839 …utedActionMetadata contains details about a completed execution. # The details of the execution th…
840 … "outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
841 …"workerCompletedTimestamp": "A String", # When the worker completed the action, including all stag…
842 "queuedTimestamp": "A String", # When was the action added to the queue.
843 "worker": "A String", # The name of the worker which ran the execution.
844 … "executionStartTimestamp": "A String", # When the worker started executing the action command.
845 "inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
846 "workerStartTimestamp": "A String", # When the worker received the action.
847 … "outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
848 …"executionCompletedTimestamp": "A String", # When the worker completed executing the action comman…
849 … "inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
851 …"outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. T…
853 # outside of the working directory, if the server supports
855 # For each output file requested in the `output_files` field of the Action,
856 # if the corresponding file existed after
857 # the action completed, a single entry will be present either in this field,
858 # or in the `output_files` field, if the file was not a symbolic link.
860 # If an output symbolic link of the same name was found, but its target
861 # type was not a regular file, the server will return a FAILED_PRECONDITION.
862 # If the action does not produce the requested output, then that output
863 # will be omitted from the list. The server is free to arrange the output
864 # list as desired; clients MUST NOT assume that the output list is sorted.
870 …"path": "A String", # The full path of the symlink relative to the working directory, including the
871 # filename. The path separator is a forward slash `/`. Since this is a
873 … "target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.
874 # The target path can be relative to the parent directory of the symlink or
876 # can be checked using the Capabilities
877 # API. The canonical form forbids the substrings `/./` and `//` in the target
878 # path. `..` components are allowed anywhere in the target path.
881 …digest for a given blob consists of the size of the blob # The digest for a blob containing the st…
882 # can be retrieved from the
884 # and its hash. The hash algorithm to use is defined by the server, but servers
887 # The size is considered to be an integral part of the digest and cannot be
888 # separated. That is, even if the `hash` field is correctly specified but
889 # `size_bytes` is not, the server MUST reject the request.
891 # The reason for including the size in the digest is as follows: in a great
892 # many cases, the server needs to know the size of the blob it is about to work
894 # structures or streaming it to a worker. Technically, the server could
896 # complicated implementation as opposed to having the client specify the size
897 # up-front (or storing the size along with the digest in every message where
898 # digests are embedded). This does mean that the API leaks some implementation
902 # When a `Digest` is used to refer to a proto message, it always refers to the
904 # servers MUST ensure that they serialize messages according to the following
905 # rules, even if there are alternate valid encodings for the same message:
910 # * Fields are serialized according to the default semantics for their type.
915 "sizeBytes": "A String", # The size of the blob, in bytes.
916 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
919 … "stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline
920 # stdout unless requested by the client in the
922 # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
923 # would cause the response to exceed message size limits.
924 … "stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline
925 # stderr unless requested by the client in the
927 # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
928 # would cause the response to exceed message size limits.
929 …igest for a given blob consists of the size of the blob # The digest for a blob containing the sta…
930 # can be retrieved from the
932 # and its hash. The hash algorithm to use is defined by the server, but servers
935 # The size is considered to be an integral part of the digest and cannot be
936 # separated. That is, even if the `hash` field is correctly specified but
937 # `size_bytes` is not, the server MUST reject the request.
939 # The reason for including the size in the digest is as follows: in a great
940 # many cases, the server needs to know the size of the blob it is about to work
942 # structures or streaming it to a worker. Technically, the server could
944 # complicated implementation as opposed to having the client specify the size
945 # up-front (or storing the size along with the digest in every message where
946 # digests are embedded). This does mean that the API leaks some implementation
950 # When a `Digest` is used to refer to a proto message, it always refers to the
952 # servers MUST ensure that they serialize messages according to the following
953 # rules, even if there are alternate valid encodings for the same message:
958 # * Fields are serialized according to the default semantics for their type.
963 "sizeBytes": "A String", # The size of the blob, in bytes.
964 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
967 "outputFiles": [ # The output files of the action. For each output file requested in the
968 # `output_files` field of the Action, if the corresponding file existed after
969 # the action completed, a single entry will be present either in this field,
970 # or the `output_file_symlinks` field if the file was a symbolic link to
973 # If an output of the same name was found, but was a directory rather
974 # than a regular file, the server will return a FAILED_PRECONDITION.
975 # If the action does not produce the requested output, then that output
976 # will be omitted from the list. The server is free to arrange the output
977 # list as desired; clients MUST NOT assume that the output list is sorted.
982 … "path": "A String", # The full path of the file relative to the working directory, including the
983 # filename. The path separator is a forward slash `/`. Since this is a
986 …"contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NO…
987 # file contents unless requested by the client in the
989 # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
990 # would cause the response to exceed message size limits.
991 …A content digest. A digest for a given blob consists of the size of the blob # The digest of the f…
992 # and its hash. The hash algorithm to use is defined by the server, but servers
995 # The size is considered to be an integral part of the digest and cannot be
996 # separated. That is, even if the `hash` field is correctly specified but
997 # `size_bytes` is not, the server MUST reject the request.
999 # The reason for including the size in the digest is as follows: in a great
1000 # many cases, the server needs to know the size of the blob it is about to work
1002 # structures or streaming it to a worker. Technically, the server could
1004 # complicated implementation as opposed to having the client specify the size
1005 # up-front (or storing the size along with the digest in every message where
1006 # digests are embedded). This does mean that the API leaks some implementation
1010 # When a `Digest` is used to refer to a proto message, it always refers to the
1012 # servers MUST ensure that they serialize messages according to the following
1013 # rules, even if there are alternate valid encodings for the same message:
1018 # * Fields are serialized according to the default semantics for their type.
1023 "sizeBytes": "A String", # The size of the blob, in bytes.
1024 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
1029 …"outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to oth…
1031 # directories, or even absolute paths outside of the working directory,
1032 # if the server supports
1034 # For each output directory requested in the `output_directories` field of
1035 # the Action, if the directory existed after the action completed, a
1036 # single entry will be present either in this field, or in the
1037 # `output_directories` field, if the directory was not a symbolic link.
1039 # If an output of the same name was found, but was a symbolic link to a file
1040 # instead of a directory, the server will return a FAILED_PRECONDITION.
1041 # If the action does not produce the requested output, then that output
1042 # will be omitted from the list. The server is free to arrange the output
1043 # list as desired; clients MUST NOT assume that the output list is sorted.
1049 …"path": "A String", # The full path of the symlink relative to the working directory, including the
1050 # filename. The path separator is a forward slash `/`. Since this is a
1052 … "target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.
1053 # The target path can be relative to the parent directory of the symlink or
1055 # can be checked using the Capabilities
1056 # API. The canonical form forbids the substrings `/./` and `//` in the target
1057 # path. `..` components are allowed anywhere in the target path.
1060 … "outputDirectories": [ # The output directories of the action. For each output directory requested
1061 # in the `output_directories` field of the Action, if the corresponding
1062 # directory existed after the action completed, a single entry will be
1063 # present in the output list, which will contain the digest of a
1064 # Tree message containing the
1065 # directory tree, and the path equal exactly to the corresponding Action
1068 # As an example, suppose the Action had an output directory `a/b/dir` and the
1069 # execution produced the following contents in `a/b/dir`: a file named `bar`
1119 # If an output of the same name was found, but was not a directory, the
1121 { # An `OutputDirectory` is the output in an `ActionResult` corresponding to a
1123 … "path": "A String", # The full path of the directory relative to the working directory. The path
1125 # NOT begin with a leading forward slash. The empty string value is allowed,
1126 # and it denotes the entire working directory.
1127 …A content digest. A digest for a given blob consists of the size of the blob # The digest of the e…
1128 # Tree proto containing the
1130 # and its hash. The hash algorithm to use is defined by the server, but servers
1133 # The size is considered to be an integral part of the digest and cannot be
1134 # separated. That is, even if the `hash` field is correctly specified but
1135 # `size_bytes` is not, the server MUST reject the request.
1137 # The reason for including the size in the digest is as follows: in a great
1138 # many cases, the server needs to know the size of the blob it is about to work
1140 # structures or streaming it to a worker. Technically, the server could
1142 # complicated implementation as opposed to having the client specify the size
1143 # up-front (or storing the size along with the digest in every message where
1144 # digests are embedded). This does mean that the API leaks some implementation
1148 # When a `Digest` is used to refer to a proto message, it always refers to the
1150 # servers MUST ensure that they serialize messages according to the following
1151 # rules, even if there are alternate valid encodings for the same message:
1156 # * Fields are serialized according to the default semantics for their type.
1161 "sizeBytes": "A String", # The size of the blob, in bytes.
1162 … "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
1167 "exitCode": 42, # The exit code of the command.