docs: docs update (#911)
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
- [ ] Make sure to open an issue as a [bug/issue](https://github.com/googleapis/google-api-python-client/issues/new/choose) before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
- [ ] Ensure the tests and linter pass
- [ ] Code coverage does not decrease (if any source code was changed)
- [ ] Appropriate docs were updated (if necessary)
Fixes #<issue_number_goes_here> 🦕
diff --git a/docs/dyn/remotebuildexecution_v2.actionResults.html b/docs/dyn/remotebuildexecution_v2.actionResults.html
index f661222..d4b1bd5 100644
--- a/docs/dyn/remotebuildexecution_v2.actionResults.html
+++ b/docs/dyn/remotebuildexecution_v2.actionResults.html
@@ -75,14 +75,14 @@
<h1><a href="remotebuildexecution_v2.html">Remote Build Execution API</a> . <a href="remotebuildexecution_v2.actionResults.html">actionResults</a></h1>
<h2>Instance Methods</h2>
<p class="toc_element">
- <code><a href="#get">get(instanceName, hash, sizeBytes, inlineStdout=None, inlineOutputFiles=None, inlineStderr=None, x__xgafv=None)</a></code></p>
+ <code><a href="#get">get(instanceName, hash, sizeBytes, inlineStderr=None, inlineOutputFiles=None, inlineStdout=None, x__xgafv=None)</a></code></p>
<p class="firstline">Retrieve a cached execution result.</p>
<p class="toc_element">
<code><a href="#update">update(instanceName, hash, sizeBytes, body=None, resultsCachePolicy_priority=None, x__xgafv=None)</a></code></p>
<p class="firstline">Upload a new execution result.</p>
<h3>Method Details</h3>
<div class="method">
- <code class="details" id="get">get(instanceName, hash, sizeBytes, inlineStdout=None, inlineOutputFiles=None, inlineStderr=None, x__xgafv=None)</code>
+ <code class="details" id="get">get(instanceName, hash, sizeBytes, inlineStderr=None, inlineOutputFiles=None, inlineStdout=None, x__xgafv=None)</code>
<pre>Retrieve a cached execution result.
Implementations SHOULD ensure that any blobs referenced from the
@@ -105,12 +105,12 @@
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)
- inlineStdout: boolean, A hint to the server to request inlining stdout in the
+ inlineStderr: boolean, A hint to the server to request inlining stderr in the
ActionResult message.
inlineOutputFiles: string, A hint to the server to inline the contents of the listed output files.
Each path needs to exactly match one path in `output_files` in the
Command message. (repeated)
- inlineStderr: boolean, A hint to the server to request inlining stderr in the
+ inlineStdout: boolean, A hint to the server to request inlining stdout in the
ActionResult message.
x__xgafv: string, V1 error format.
Allowed values
@@ -121,414 +121,414 @@
An object of the form:
{ # An ActionResult represents the result of an
- # Action being run.
- "executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.
- "outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
- "workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.
- "queuedTimestamp": "A String", # When was the action added to the queue.
- "worker": "A String", # The name of the worker which ran the execution.
- "executionStartTimestamp": "A String", # When the worker started executing the action command.
- "inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
- "workerStartTimestamp": "A String", # When the worker received the action.
- "outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
- "executionCompletedTimestamp": "A String", # When the worker completed executing the action command.
- "inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
- },
- "outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. Those
- # may be links to other output files, or input files, or even absolute paths
- # outside of the working directory, if the server supports
- # SymlinkAbsolutePathStrategy.ALLOWED.
- # For each output file requested in the `output_files` or `output_paths`
- # field of the Action, if the corresponding file existed after
- # the action completed, a single entry will be present either in this field,
- # or in the `output_files` field, if the file was not a symbolic link.
+ # Action being run.
+ "outputSymlinks": [ # New in v2.1: this field will only be populated if the command
+ # `output_paths` field was used, and not the pre v2.1 `output_files` or
+ # `output_directories` fields.
+ # The output paths of the action that are symbolic links to other paths. Those
+ # may be links to other outputs, or inputs, or even absolute paths
+ # outside of the working directory, if the server supports
+ # SymlinkAbsolutePathStrategy.ALLOWED.
+ # A single entry for each output requested in `output_paths`
+ # field of the Action, if the corresponding path existed after
+ # the action completed and was a symbolic link.
+ #
+ # If the action does not produce a requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ { # An `OutputSymlink` is similar to a
+ # Symlink, but it is used as an
+ # output in an `ActionResult`.
#
- # If an output symbolic link of the same name as listed in `output_files` of
- # the Command was found, but its target type was not a regular file, the
- # server will return a FAILED_PRECONDITION.
- # If the action does not produce the requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- #
- # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
- # should still populate this field in addition to `output_symlinks`.
- { # An `OutputSymlink` is similar to a
- # Symlink, but it is used as an
- # output in an `ActionResult`.
- #
- # `OutputSymlink` is binary-compatible with `SymlinkNode`.
- "path": "A String", # The full path of the symlink relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
- # Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- },
- ],
- "stderrDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard error of the action, which
- # can be retrieved from the
- # ContentAddressableStorage.
- # and its hash. The hash algorithm to use is defined by the server.
- #
- # The size is considered to be an integral part of the digest and cannot be
- # separated. That is, even if the `hash` field is correctly specified but
- # `size_bytes` is not, the server MUST reject the request.
- #
- # The reason for including the size in the digest is as follows: in a great
- # many cases, the server needs to know the size of the blob it is about to work
- # with prior to starting an operation with it, such as flattening Merkle tree
- # structures or streaming it to a worker. Technically, the server could
- # implement a separate metadata store, but this results in a significantly more
- # complicated implementation as opposed to having the client specify the size
- # up-front (or storing the size along with the digest in every message where
- # digests are embedded). This does mean that the API leaks some implementation
- # details of (what we consider to be) a reasonable server implementation, but
- # we consider this to be a worthwhile tradeoff.
- #
- # When a `Digest` is used to refer to a proto message, it always refers to the
- # message in binary encoded form. To ensure consistent hashing, clients and
- # servers MUST ensure that they serialize messages according to the following
- # rules, even if there are alternate valid encodings for the same message:
- #
- # * Fields are serialized in tag order.
- # * There are no unknown fields.
- # * There are no duplicate fields.
- # * Fields are serialized according to the default semantics for their type.
- #
- # Most protocol buffer implementations will always follow these rules when
- # serializing, but care should be taken to avoid shortcuts. For instance,
- # concatenating two messages to merge them may produce duplicate fields.
- "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.
- },
- "stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline
- # stdout unless requested by the client in the
- # GetActionResultRequest
- # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
- # would cause the response to exceed message size limits.
- "stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline
- # stderr unless requested by the client in the
- # GetActionResultRequest
- # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
- # would cause the response to exceed message size limits.
- "stdoutDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard output of the action, which
- # can be retrieved from the
- # ContentAddressableStorage.
- # and its hash. The hash algorithm to use is defined by the server.
- #
- # The size is considered to be an integral part of the digest and cannot be
- # separated. That is, even if the `hash` field is correctly specified but
- # `size_bytes` is not, the server MUST reject the request.
- #
- # The reason for including the size in the digest is as follows: in a great
- # many cases, the server needs to know the size of the blob it is about to work
- # with prior to starting an operation with it, such as flattening Merkle tree
- # structures or streaming it to a worker. Technically, the server could
- # implement a separate metadata store, but this results in a significantly more
- # complicated implementation as opposed to having the client specify the size
- # up-front (or storing the size along with the digest in every message where
- # digests are embedded). This does mean that the API leaks some implementation
- # details of (what we consider to be) a reasonable server implementation, but
- # we consider this to be a worthwhile tradeoff.
- #
- # When a `Digest` is used to refer to a proto message, it always refers to the
- # message in binary encoded form. To ensure consistent hashing, clients and
- # servers MUST ensure that they serialize messages according to the following
- # rules, even if there are alternate valid encodings for the same message:
- #
- # * Fields are serialized in tag order.
- # * There are no unknown fields.
- # * There are no duplicate fields.
- # * Fields are serialized according to the default semantics for their type.
- #
- # Most protocol buffer implementations will always follow these rules when
- # serializing, but care should be taken to avoid shortcuts. For instance,
- # concatenating two messages to merge them may produce duplicate fields.
- "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.
- },
- "outputSymlinks": [ # New in v2.1: this field will only be populated if the command
- # `output_paths` field was used, and not the pre v2.1 `output_files` or
- # `output_directories` fields.
- # The output paths of the action that are symbolic links to other paths. Those
- # may be links to other outputs, or inputs, or even absolute paths
- # outside of the working directory, if the server supports
- # SymlinkAbsolutePathStrategy.ALLOWED.
- # A single entry for each output requested in `output_paths`
- # field of the Action, if the corresponding path existed after
- # the action completed and was a symbolic link.
- #
- # If the action does not produce a requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- { # An `OutputSymlink` is similar to a
- # Symlink, but it is used as an
- # output in an `ActionResult`.
- #
- # `OutputSymlink` is binary-compatible with `SymlinkNode`.
- "path": "A String", # The full path of the symlink relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
- # Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- },
- ],
- "outputFiles": [ # The output files of the action. For each output file requested in the
- # `output_files` or `output_paths` field of the Action, if the corresponding
- # file existed after the action completed, a single entry will be present
- # either in this field, or the `output_file_symlinks` field if the file was
- # a symbolic link to another file (`output_symlinks` field after v2.1).
- #
- # If an output listed in `output_files` was found, but was a directory rather
- # than a regular file, the server will return a FAILED_PRECONDITION.
- # If the action does not produce the requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- { # An `OutputFile` is similar to a
- # FileNode, but it is used as an
- # output in an `ActionResult`. It allows a full file path rather than
- # only a name.
- "path": "A String", # The full path of the file relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "isExecutable": True or False, # True if file is executable, false otherwise.
- "nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- #
- # 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.
+ # `OutputSymlink` is binary-compatible with `SymlinkNode`.
+ "path": "A String", # The full path of the symlink relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
+ # Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
},
- "contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NOT inline
- # file contents unless requested by the client in the
- # GetActionResultRequest
- # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
- # would cause the response to exceed message size limits.
- },
- ],
- "outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to other
- # directories. Those may be links to other output directories, or input
- # directories, or even absolute paths outside of the working directory,
- # if the server supports
- # SymlinkAbsolutePathStrategy.ALLOWED.
- # For each output directory requested in the `output_directories` field of
- # the Action, if the directory existed after the action completed, a
- # single entry will be present either in this field, or in the
- # `output_directories` field, if the directory was not a symbolic link.
+ ],
+ "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.
+ },
+ ],
+ "outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to other
+ # directories. Those may be links to other output directories, or input
+ # directories, or even absolute paths outside of the working directory,
+ # if the server supports
+ # SymlinkAbsolutePathStrategy.ALLOWED.
+ # For each output directory requested in the `output_directories` field of
+ # the Action, if the directory existed after the action completed, a
+ # single entry will be present either in this field, or in the
+ # `output_directories` field, if the directory was not a symbolic link.
+ #
+ # If an output of the same name was found, but was a symbolic link to a file
+ # instead of a directory, the server will return a FAILED_PRECONDITION.
+ # If the action does not produce the requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ #
+ # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
+ # should still populate this field in addition to `output_symlinks`.
+ { # An `OutputSymlink` is similar to a
+ # Symlink, but it is used as an
+ # output in an `ActionResult`.
#
- # If an output of the same name was found, but was a symbolic link to a file
- # instead of a directory, the server will return a FAILED_PRECONDITION.
- # If the action does not produce the requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- #
- # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
- # should still populate this field in addition to `output_symlinks`.
- { # An `OutputSymlink` is similar to a
- # Symlink, but it is used as an
- # output in an `ActionResult`.
- #
- # `OutputSymlink` is binary-compatible with `SymlinkNode`.
- "path": "A String", # The full path of the symlink relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
- # Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- },
- ],
- "outputDirectories": [ # The output directories of the action. For each output directory requested
- # in the `output_directories` or `output_paths` field of the Action, if the
- # corresponding directory existed after the action completed, a single entry
- # will be present in the output list, which will contain the digest of a
- # Tree message containing the
- # directory tree, and the path equal exactly to the corresponding Action
- # output_directories member.
- #
- # As an example, suppose the Action had an output directory `a/b/dir` and the
- # execution produced the following contents in `a/b/dir`: a file named `bar`
- # and a directory named `foo` with an executable file named `baz`. Then,
- # output_directory will contain (hashes shortened for readability):
- #
- # ```json
- # // OutputDirectory proto:
- # {
- # path: "a/b/dir"
- # tree_digest: {
- # hash: "4a73bc9d03...",
- # size: 55
- # }
- # }
- # // Tree proto with hash "4a73bc9d03..." and size 55:
- # {
- # root: {
- # files: [
- # {
- # name: "bar",
- # digest: {
- # hash: "4a73bc9d03...",
- # size: 65534
- # }
- # }
- # ],
- # directories: [
- # {
- # name: "foo",
- # digest: {
- # hash: "4cf2eda940...",
- # size: 43
- # }
- # }
- # ]
- # }
- # children : {
- # // (Directory proto with hash "4cf2eda940..." and size 43)
- # files: [
- # {
- # name: "baz",
- # digest: {
- # hash: "b2c941073e...",
- # size: 1294,
- # },
- # is_executable: true
- # }
- # ]
- # }
- # }
- # ```
- # If an output of the same name as listed in `output_files` of
- # the Command was found in `output_directories`, but was not a directory, the
- # server will return a FAILED_PRECONDITION.
- { # An `OutputDirectory` is the output in an `ActionResult` corresponding to a
- # directory's full contents rather than a single file.
- "path": "A String", # The full path of the directory relative to the working directory. The path
- # separator is a forward slash `/`. Since this is a relative path, it MUST
- # NOT begin with a leading forward slash. The empty string value is allowed,
- # and it denotes the entire working directory.
- "treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the encoded
- # Tree proto containing the
- # directory's contents.
- # and its hash. The hash algorithm to use is defined by the server.
- #
- # The size is considered to be an integral part of the digest and cannot be
- # separated. That is, even if the `hash` field is correctly specified but
- # `size_bytes` is not, the server MUST reject the request.
- #
- # The reason for including the size in the digest is as follows: in a great
- # many cases, the server needs to know the size of the blob it is about to work
- # with prior to starting an operation with it, such as flattening Merkle tree
- # structures or streaming it to a worker. Technically, the server could
- # implement a separate metadata store, but this results in a significantly more
- # complicated implementation as opposed to having the client specify the size
- # up-front (or storing the size along with the digest in every message where
- # digests are embedded). This does mean that the API leaks some implementation
- # details of (what we consider to be) a reasonable server implementation, but
- # we consider this to be a worthwhile tradeoff.
- #
- # When a `Digest` is used to refer to a proto message, it always refers to the
- # message in binary encoded form. To ensure consistent hashing, clients and
- # servers MUST ensure that they serialize messages according to the following
- # rules, even if there are alternate valid encodings for the same message:
- #
- # * Fields are serialized in tag order.
- # * There are no unknown fields.
- # * There are no duplicate fields.
- # * Fields are serialized according to the default semantics for their type.
- #
- # Most protocol buffer implementations will always follow these rules when
- # serializing, but care should be taken to avoid shortcuts. For instance,
- # concatenating two messages to merge them may produce duplicate fields.
- "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.
+ # `OutputSymlink` is binary-compatible with `SymlinkNode`.
+ "path": "A String", # The full path of the symlink relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
+ # Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
},
+ ],
+ "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.
+ },
+ ],
+ "stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline
+ # stderr unless requested by the client in the
+ # GetActionResultRequest
+ # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
+ # would cause the response to exceed message size limits.
+ "stdoutDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard output of the action, which
+ # can be retrieved from the
+ # ContentAddressableStorage.
+ # and its hash. The hash algorithm to use is defined by the server.
+ #
+ # The size is considered to be an integral part of the digest and cannot be
+ # separated. That is, even if the `hash` field is correctly specified but
+ # `size_bytes` is not, the server MUST reject the request.
+ #
+ # The reason for including the size in the digest is as follows: in a great
+ # many cases, the server needs to know the size of the blob it is about to work
+ # with prior to starting an operation with it, such as flattening Merkle tree
+ # structures or streaming it to a worker. Technically, the server could
+ # implement a separate metadata store, but this results in a significantly more
+ # complicated implementation as opposed to having the client specify the size
+ # up-front (or storing the size along with the digest in every message where
+ # digests are embedded). This does mean that the API leaks some implementation
+ # details of (what we consider to be) a reasonable server implementation, but
+ # we consider this to be a worthwhile tradeoff.
+ #
+ # When a `Digest` is used to refer to a proto message, it always refers to the
+ # message in binary encoded form. To ensure consistent hashing, clients and
+ # servers MUST ensure that they serialize messages according to the following
+ # rules, even if there are alternate valid encodings for the same message:
+ #
+ # * Fields are serialized in tag order.
+ # * There are no unknown fields.
+ # * There are no duplicate fields.
+ # * Fields are serialized according to the default semantics for their type.
+ #
+ # Most protocol buffer implementations will always follow these rules when
+ # serializing, but care should be taken to avoid shortcuts. For instance,
+ # concatenating two messages to merge them may produce duplicate fields.
+ "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.
+ },
+ "exitCode": 42, # The exit code of the command.
+ "outputDirectories": [ # The output directories of the action. For each output directory requested
+ # in the `output_directories` or `output_paths` field of the Action, if the
+ # corresponding directory existed after the action completed, a single entry
+ # will be present in the output list, which will contain the digest of a
+ # Tree message containing the
+ # directory tree, and the path equal exactly to the corresponding Action
+ # output_directories member.
+ #
+ # As an example, suppose the Action had an output directory `a/b/dir` and the
+ # execution produced the following contents in `a/b/dir`: a file named `bar`
+ # and a directory named `foo` with an executable file named `baz`. Then,
+ # output_directory will contain (hashes shortened for readability):
+ #
+ # ```json
+ # // OutputDirectory proto:
+ # {
+ # path: "a/b/dir"
+ # tree_digest: {
+ # hash: "4a73bc9d03...",
+ # size: 55
+ # }
+ # }
+ # // Tree proto with hash "4a73bc9d03..." and size 55:
+ # {
+ # root: {
+ # files: [
+ # {
+ # name: "bar",
+ # digest: {
+ # hash: "4a73bc9d03...",
+ # size: 65534
+ # }
+ # }
+ # ],
+ # directories: [
+ # {
+ # name: "foo",
+ # digest: {
+ # hash: "4cf2eda940...",
+ # size: 43
+ # }
+ # }
+ # ]
+ # }
+ # children : {
+ # // (Directory proto with hash "4cf2eda940..." and size 43)
+ # files: [
+ # {
+ # name: "baz",
+ # digest: {
+ # hash: "b2c941073e...",
+ # size: 1294,
+ # },
+ # is_executable: true
+ # }
+ # ]
+ # }
+ # }
+ # ```
+ # If an output of the same name as listed in `output_files` of
+ # the Command was found in `output_directories`, but was not a directory, the
+ # server will return a FAILED_PRECONDITION.
+ { # An `OutputDirectory` is the output in an `ActionResult` corresponding to a
+ # directory's full contents rather than a single file.
+ "treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the encoded
+ # Tree proto containing the
+ # directory's contents.
+ # and its hash. The hash algorithm to use is defined by the server.
+ #
+ # The size is considered to be an integral part of the digest and cannot be
+ # separated. That is, even if the `hash` field is correctly specified but
+ # `size_bytes` is not, the server MUST reject the request.
+ #
+ # The reason for including the size in the digest is as follows: in a great
+ # many cases, the server needs to know the size of the blob it is about to work
+ # with prior to starting an operation with it, such as flattening Merkle tree
+ # structures or streaming it to a worker. Technically, the server could
+ # implement a separate metadata store, but this results in a significantly more
+ # complicated implementation as opposed to having the client specify the size
+ # up-front (or storing the size along with the digest in every message where
+ # digests are embedded). This does mean that the API leaks some implementation
+ # details of (what we consider to be) a reasonable server implementation, but
+ # we consider this to be a worthwhile tradeoff.
+ #
+ # When a `Digest` is used to refer to a proto message, it always refers to the
+ # message in binary encoded form. To ensure consistent hashing, clients and
+ # servers MUST ensure that they serialize messages according to the following
+ # rules, even if there are alternate valid encodings for the same message:
+ #
+ # * Fields are serialized in tag order.
+ # * There are no unknown fields.
+ # * There are no duplicate fields.
+ # * Fields are serialized according to the default semantics for their type.
+ #
+ # Most protocol buffer implementations will always follow these rules when
+ # serializing, but care should be taken to avoid shortcuts. For instance,
+ # concatenating two messages to merge them may produce duplicate fields.
+ "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.
},
- ],
- "exitCode": 42, # The exit code of the command.
- }</pre>
+ "path": "A String", # The full path of the directory relative to the working directory. The path
+ # separator is a forward slash `/`. Since this is a relative path, it MUST
+ # NOT begin with a leading forward slash. The empty string value is allowed,
+ # and it denotes the entire working directory.
+ },
+ ],
+ "stderrDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard error of the action, which
+ # can be retrieved from the
+ # ContentAddressableStorage.
+ # and its hash. The hash algorithm to use is defined by the server.
+ #
+ # The size is considered to be an integral part of the digest and cannot be
+ # separated. That is, even if the `hash` field is correctly specified but
+ # `size_bytes` is not, the server MUST reject the request.
+ #
+ # The reason for including the size in the digest is as follows: in a great
+ # many cases, the server needs to know the size of the blob it is about to work
+ # with prior to starting an operation with it, such as flattening Merkle tree
+ # structures or streaming it to a worker. Technically, the server could
+ # implement a separate metadata store, but this results in a significantly more
+ # complicated implementation as opposed to having the client specify the size
+ # up-front (or storing the size along with the digest in every message where
+ # digests are embedded). This does mean that the API leaks some implementation
+ # details of (what we consider to be) a reasonable server implementation, but
+ # we consider this to be a worthwhile tradeoff.
+ #
+ # When a `Digest` is used to refer to a proto message, it always refers to the
+ # message in binary encoded form. To ensure consistent hashing, clients and
+ # servers MUST ensure that they serialize messages according to the following
+ # rules, even if there are alternate valid encodings for the same message:
+ #
+ # * Fields are serialized in tag order.
+ # * There are no unknown fields.
+ # * There are no duplicate fields.
+ # * Fields are serialized according to the default semantics for their type.
+ #
+ # Most protocol buffer implementations will always follow these rules when
+ # serializing, but care should be taken to avoid shortcuts. For instance,
+ # concatenating two messages to merge them may produce duplicate fields.
+ "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.
+ },
+ "outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. Those
+ # may be links to other output files, or input files, or even absolute paths
+ # outside of the working directory, if the server supports
+ # SymlinkAbsolutePathStrategy.ALLOWED.
+ # For each output file requested in the `output_files` or `output_paths`
+ # field of the Action, if the corresponding file existed after
+ # the action completed, a single entry will be present either in this field,
+ # or in the `output_files` field, if the file was not a symbolic link.
+ #
+ # If an output symbolic link of the same name as listed in `output_files` of
+ # the Command was found, but its target type was not a regular file, the
+ # server will return a FAILED_PRECONDITION.
+ # If the action does not produce the requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ #
+ # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
+ # should still populate this field in addition to `output_symlinks`.
+ { # An `OutputSymlink` is similar to a
+ # Symlink, but it is used as an
+ # output in an `ActionResult`.
+ #
+ # `OutputSymlink` is binary-compatible with `SymlinkNode`.
+ "path": "A String", # The full path of the symlink relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
+ # Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
+ },
+ ],
+ "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.
+ },
+ ],
+ "stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline
+ # stdout unless requested by the client in the
+ # GetActionResultRequest
+ # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
+ # would cause the response to exceed message size limits.
+ "outputFiles": [ # The output files of the action. For each output file requested in the
+ # `output_files` or `output_paths` field of the Action, if the corresponding
+ # file existed after the action completed, a single entry will be present
+ # either in this field, or the `output_file_symlinks` field if the file was
+ # a symbolic link to another file (`output_symlinks` field after v2.1).
+ #
+ # If an output listed in `output_files` was found, but was a directory rather
+ # than a regular file, the server will return a FAILED_PRECONDITION.
+ # If the action does not produce the requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ { # An `OutputFile` is similar to a
+ # FileNode, but it is used as an
+ # output in an `ActionResult`. It allows a full file path rather than
+ # only a name.
+ "isExecutable": True or False, # True if file is executable, false otherwise.
+ "path": "A String", # The full path of the file relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NOT inline
+ # file contents unless requested by the client in the
+ # GetActionResultRequest
+ # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
+ # would cause the response to exceed message size limits.
+ "nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
+ },
+ ],
+ "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.
+ #
+ # 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.
+ },
+ },
+ ],
+ "executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.
+ "workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.
+ "outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
+ "workerStartTimestamp": "A String", # When the worker received the action.
+ "queuedTimestamp": "A String", # When was the action added to the queue.
+ "inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
+ "executionCompletedTimestamp": "A String", # When the worker completed executing the action command.
+ "outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
+ "worker": "A String", # The name of the worker which ran the execution.
+ "executionStartTimestamp": "A String", # When the worker started executing the action command.
+ "inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
+ },
+ }</pre>
</div>
<div class="method">
@@ -563,414 +563,414 @@
The object takes the form of:
{ # An ActionResult represents the result of an
- # Action being run.
- "executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.
- "outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
- "workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.
- "queuedTimestamp": "A String", # When was the action added to the queue.
- "worker": "A String", # The name of the worker which ran the execution.
- "executionStartTimestamp": "A String", # When the worker started executing the action command.
- "inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
- "workerStartTimestamp": "A String", # When the worker received the action.
- "outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
- "executionCompletedTimestamp": "A String", # When the worker completed executing the action command.
- "inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
- },
- "outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. Those
- # may be links to other output files, or input files, or even absolute paths
- # outside of the working directory, if the server supports
- # SymlinkAbsolutePathStrategy.ALLOWED.
- # For each output file requested in the `output_files` or `output_paths`
- # field of the Action, if the corresponding file existed after
- # the action completed, a single entry will be present either in this field,
- # or in the `output_files` field, if the file was not a symbolic link.
- #
- # If an output symbolic link of the same name as listed in `output_files` of
- # the Command was found, but its target type was not a regular file, the
- # server will return a FAILED_PRECONDITION.
- # If the action does not produce the requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- #
- # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
- # should still populate this field in addition to `output_symlinks`.
- { # An `OutputSymlink` is similar to a
- # Symlink, but it is used as an
- # output in an `ActionResult`.
- #
- # `OutputSymlink` is binary-compatible with `SymlinkNode`.
- "path": "A String", # The full path of the symlink relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
- # Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- },
- ],
- "stderrDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard error of the action, which
- # can be retrieved from the
- # ContentAddressableStorage.
- # and its hash. The hash algorithm to use is defined by the server.
+ # Action being run.
+ "outputSymlinks": [ # New in v2.1: this field will only be populated if the command
+ # `output_paths` field was used, and not the pre v2.1 `output_files` or
+ # `output_directories` fields.
+ # The output paths of the action that are symbolic links to other paths. Those
+ # may be links to other outputs, or inputs, or even absolute paths
+ # outside of the working directory, if the server supports
+ # SymlinkAbsolutePathStrategy.ALLOWED.
+ # A single entry for each output requested in `output_paths`
+ # field of the Action, if the corresponding path existed after
+ # the action completed and was a symbolic link.
+ #
+ # If the action does not produce a requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ { # An `OutputSymlink` is similar to a
+ # Symlink, but it is used as an
+ # output in an `ActionResult`.
#
- # 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.
- },
- "stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline
- # stdout unless requested by the client in the
- # GetActionResultRequest
- # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
- # would cause the response to exceed message size limits.
- "stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline
- # stderr unless requested by the client in the
- # GetActionResultRequest
- # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
- # would cause the response to exceed message size limits.
- "stdoutDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard output of the action, which
- # can be retrieved from the
- # ContentAddressableStorage.
- # and its hash. The hash algorithm to use is defined by the server.
- #
- # The size is considered to be an integral part of the digest and cannot be
- # separated. That is, even if the `hash` field is correctly specified but
- # `size_bytes` is not, the server MUST reject the request.
- #
- # The reason for including the size in the digest is as follows: in a great
- # many cases, the server needs to know the size of the blob it is about to work
- # with prior to starting an operation with it, such as flattening Merkle tree
- # structures or streaming it to a worker. Technically, the server could
- # implement a separate metadata store, but this results in a significantly more
- # complicated implementation as opposed to having the client specify the size
- # up-front (or storing the size along with the digest in every message where
- # digests are embedded). This does mean that the API leaks some implementation
- # details of (what we consider to be) a reasonable server implementation, but
- # we consider this to be a worthwhile tradeoff.
- #
- # When a `Digest` is used to refer to a proto message, it always refers to the
- # message in binary encoded form. To ensure consistent hashing, clients and
- # servers MUST ensure that they serialize messages according to the following
- # rules, even if there are alternate valid encodings for the same message:
- #
- # * Fields are serialized in tag order.
- # * There are no unknown fields.
- # * There are no duplicate fields.
- # * Fields are serialized according to the default semantics for their type.
- #
- # Most protocol buffer implementations will always follow these rules when
- # serializing, but care should be taken to avoid shortcuts. For instance,
- # concatenating two messages to merge them may produce duplicate fields.
- "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.
- },
- "outputSymlinks": [ # New in v2.1: this field will only be populated if the command
- # `output_paths` field was used, and not the pre v2.1 `output_files` or
- # `output_directories` fields.
- # The output paths of the action that are symbolic links to other paths. Those
- # may be links to other outputs, or inputs, or even absolute paths
- # outside of the working directory, if the server supports
- # SymlinkAbsolutePathStrategy.ALLOWED.
- # A single entry for each output requested in `output_paths`
- # field of the Action, if the corresponding path existed after
- # the action completed and was a symbolic link.
- #
- # If the action does not produce a requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- { # An `OutputSymlink` is similar to a
- # Symlink, but it is used as an
- # output in an `ActionResult`.
- #
- # `OutputSymlink` is binary-compatible with `SymlinkNode`.
- "path": "A String", # The full path of the symlink relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
- # Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- },
- ],
- "outputFiles": [ # The output files of the action. For each output file requested in the
- # `output_files` or `output_paths` field of the Action, if the corresponding
- # file existed after the action completed, a single entry will be present
- # either in this field, or the `output_file_symlinks` field if the file was
- # a symbolic link to another file (`output_symlinks` field after v2.1).
- #
- # If an output listed in `output_files` was found, but was a directory rather
- # than a regular file, the server will return a FAILED_PRECONDITION.
- # If the action does not produce the requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- { # An `OutputFile` is similar to a
- # FileNode, but it is used as an
- # output in an `ActionResult`. It allows a full file path rather than
- # only a name.
- "path": "A String", # The full path of the file relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "isExecutable": True or False, # True if file is executable, false otherwise.
- "nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- #
- # 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.
+ # `OutputSymlink` is binary-compatible with `SymlinkNode`.
+ "path": "A String", # The full path of the symlink relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
+ # Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
},
- "contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NOT inline
- # file contents unless requested by the client in the
- # GetActionResultRequest
- # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
- # would cause the response to exceed message size limits.
- },
- ],
- "outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to other
- # directories. Those may be links to other output directories, or input
- # directories, or even absolute paths outside of the working directory,
- # if the server supports
- # SymlinkAbsolutePathStrategy.ALLOWED.
- # For each output directory requested in the `output_directories` field of
- # the Action, if the directory existed after the action completed, a
- # single entry will be present either in this field, or in the
- # `output_directories` field, if the directory was not a symbolic link.
- #
- # If an output of the same name was found, but was a symbolic link to a file
- # instead of a directory, the server will return a FAILED_PRECONDITION.
- # If the action does not produce the requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- #
- # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
- # should still populate this field in addition to `output_symlinks`.
- { # An `OutputSymlink` is similar to a
- # Symlink, but it is used as an
- # output in an `ActionResult`.
- #
- # `OutputSymlink` is binary-compatible with `SymlinkNode`.
- "path": "A String", # The full path of the symlink relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
- # Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- },
- ],
- "outputDirectories": [ # The output directories of the action. For each output directory requested
- # in the `output_directories` or `output_paths` field of the Action, if the
- # corresponding directory existed after the action completed, a single entry
- # will be present in the output list, which will contain the digest of a
- # Tree message containing the
- # directory tree, and the path equal exactly to the corresponding Action
- # output_directories member.
- #
- # As an example, suppose the Action had an output directory `a/b/dir` and the
- # execution produced the following contents in `a/b/dir`: a file named `bar`
- # and a directory named `foo` with an executable file named `baz`. Then,
- # output_directory will contain (hashes shortened for readability):
- #
- # ```json
- # // OutputDirectory proto:
- # {
- # path: "a/b/dir"
- # tree_digest: {
- # hash: "4a73bc9d03...",
- # size: 55
- # }
- # }
- # // Tree proto with hash "4a73bc9d03..." and size 55:
- # {
- # root: {
- # files: [
- # {
- # name: "bar",
- # digest: {
- # hash: "4a73bc9d03...",
- # size: 65534
- # }
- # }
- # ],
- # directories: [
- # {
- # name: "foo",
- # digest: {
- # hash: "4cf2eda940...",
- # size: 43
- # }
- # }
- # ]
- # }
- # children : {
- # // (Directory proto with hash "4cf2eda940..." and size 43)
- # files: [
- # {
- # name: "baz",
- # digest: {
- # hash: "b2c941073e...",
- # size: 1294,
- # },
- # is_executable: true
- # }
- # ]
- # }
- # }
- # ```
- # If an output of the same name as listed in `output_files` of
- # the Command was found in `output_directories`, but was not a directory, the
- # server will return a FAILED_PRECONDITION.
- { # An `OutputDirectory` is the output in an `ActionResult` corresponding to a
- # directory's full contents rather than a single file.
- "path": "A String", # The full path of the directory relative to the working directory. The path
- # separator is a forward slash `/`. Since this is a relative path, it MUST
- # NOT begin with a leading forward slash. The empty string value is allowed,
- # and it denotes the entire working directory.
- "treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the encoded
- # Tree proto containing the
- # directory's contents.
- # and its hash. The hash algorithm to use is defined by the server.
- #
- # The size is considered to be an integral part of the digest and cannot be
- # separated. That is, even if the `hash` field is correctly specified but
- # `size_bytes` is not, the server MUST reject the request.
- #
- # The reason for including the size in the digest is as follows: in a great
- # many cases, the server needs to know the size of the blob it is about to work
- # with prior to starting an operation with it, such as flattening Merkle tree
- # structures or streaming it to a worker. Technically, the server could
- # implement a separate metadata store, but this results in a significantly more
- # complicated implementation as opposed to having the client specify the size
- # up-front (or storing the size along with the digest in every message where
- # digests are embedded). This does mean that the API leaks some implementation
- # details of (what we consider to be) a reasonable server implementation, but
- # we consider this to be a worthwhile tradeoff.
- #
- # When a `Digest` is used to refer to a proto message, it always refers to the
- # message in binary encoded form. To ensure consistent hashing, clients and
- # servers MUST ensure that they serialize messages according to the following
- # rules, even if there are alternate valid encodings for the same message:
- #
- # * Fields are serialized in tag order.
- # * There are no unknown fields.
- # * There are no duplicate fields.
- # * Fields are serialized according to the default semantics for their type.
- #
- # Most protocol buffer implementations will always follow these rules when
- # serializing, but care should be taken to avoid shortcuts. For instance,
- # concatenating two messages to merge them may produce duplicate fields.
- "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.
+ ],
+ "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.
+ },
+ ],
+ "outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to other
+ # directories. Those may be links to other output directories, or input
+ # directories, or even absolute paths outside of the working directory,
+ # if the server supports
+ # SymlinkAbsolutePathStrategy.ALLOWED.
+ # For each output directory requested in the `output_directories` field of
+ # the Action, if the directory existed after the action completed, a
+ # single entry will be present either in this field, or in the
+ # `output_directories` field, if the directory was not a symbolic link.
+ #
+ # If an output of the same name was found, but was a symbolic link to a file
+ # instead of a directory, the server will return a FAILED_PRECONDITION.
+ # If the action does not produce the requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ #
+ # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
+ # should still populate this field in addition to `output_symlinks`.
+ { # An `OutputSymlink` is similar to a
+ # Symlink, but it is used as an
+ # output in an `ActionResult`.
+ #
+ # `OutputSymlink` is binary-compatible with `SymlinkNode`.
+ "path": "A String", # The full path of the symlink relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
+ # Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
},
+ ],
+ "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.
+ },
+ ],
+ "stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline
+ # stderr unless requested by the client in the
+ # GetActionResultRequest
+ # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
+ # would cause the response to exceed message size limits.
+ "stdoutDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard output of the action, which
+ # can be retrieved from the
+ # ContentAddressableStorage.
+ # and its hash. The hash algorithm to use is defined by the server.
+ #
+ # The size is considered to be an integral part of the digest and cannot be
+ # separated. That is, even if the `hash` field is correctly specified but
+ # `size_bytes` is not, the server MUST reject the request.
+ #
+ # The reason for including the size in the digest is as follows: in a great
+ # many cases, the server needs to know the size of the blob it is about to work
+ # with prior to starting an operation with it, such as flattening Merkle tree
+ # structures or streaming it to a worker. Technically, the server could
+ # implement a separate metadata store, but this results in a significantly more
+ # complicated implementation as opposed to having the client specify the size
+ # up-front (or storing the size along with the digest in every message where
+ # digests are embedded). This does mean that the API leaks some implementation
+ # details of (what we consider to be) a reasonable server implementation, but
+ # we consider this to be a worthwhile tradeoff.
+ #
+ # When a `Digest` is used to refer to a proto message, it always refers to the
+ # message in binary encoded form. To ensure consistent hashing, clients and
+ # servers MUST ensure that they serialize messages according to the following
+ # rules, even if there are alternate valid encodings for the same message:
+ #
+ # * Fields are serialized in tag order.
+ # * There are no unknown fields.
+ # * There are no duplicate fields.
+ # * Fields are serialized according to the default semantics for their type.
+ #
+ # Most protocol buffer implementations will always follow these rules when
+ # serializing, but care should be taken to avoid shortcuts. For instance,
+ # concatenating two messages to merge them may produce duplicate fields.
+ "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.
+ },
+ "exitCode": 42, # The exit code of the command.
+ "outputDirectories": [ # The output directories of the action. For each output directory requested
+ # in the `output_directories` or `output_paths` field of the Action, if the
+ # corresponding directory existed after the action completed, a single entry
+ # will be present in the output list, which will contain the digest of a
+ # Tree message containing the
+ # directory tree, and the path equal exactly to the corresponding Action
+ # output_directories member.
+ #
+ # As an example, suppose the Action had an output directory `a/b/dir` and the
+ # execution produced the following contents in `a/b/dir`: a file named `bar`
+ # and a directory named `foo` with an executable file named `baz`. Then,
+ # output_directory will contain (hashes shortened for readability):
+ #
+ # ```json
+ # // OutputDirectory proto:
+ # {
+ # path: "a/b/dir"
+ # tree_digest: {
+ # hash: "4a73bc9d03...",
+ # size: 55
+ # }
+ # }
+ # // Tree proto with hash "4a73bc9d03..." and size 55:
+ # {
+ # root: {
+ # files: [
+ # {
+ # name: "bar",
+ # digest: {
+ # hash: "4a73bc9d03...",
+ # size: 65534
+ # }
+ # }
+ # ],
+ # directories: [
+ # {
+ # name: "foo",
+ # digest: {
+ # hash: "4cf2eda940...",
+ # size: 43
+ # }
+ # }
+ # ]
+ # }
+ # children : {
+ # // (Directory proto with hash "4cf2eda940..." and size 43)
+ # files: [
+ # {
+ # name: "baz",
+ # digest: {
+ # hash: "b2c941073e...",
+ # size: 1294,
+ # },
+ # is_executable: true
+ # }
+ # ]
+ # }
+ # }
+ # ```
+ # If an output of the same name as listed in `output_files` of
+ # the Command was found in `output_directories`, but was not a directory, the
+ # server will return a FAILED_PRECONDITION.
+ { # An `OutputDirectory` is the output in an `ActionResult` corresponding to a
+ # directory's full contents rather than a single file.
+ "treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the encoded
+ # Tree proto containing the
+ # directory's contents.
+ # and its hash. The hash algorithm to use is defined by the server.
+ #
+ # The size is considered to be an integral part of the digest and cannot be
+ # separated. That is, even if the `hash` field is correctly specified but
+ # `size_bytes` is not, the server MUST reject the request.
+ #
+ # The reason for including the size in the digest is as follows: in a great
+ # many cases, the server needs to know the size of the blob it is about to work
+ # with prior to starting an operation with it, such as flattening Merkle tree
+ # structures or streaming it to a worker. Technically, the server could
+ # implement a separate metadata store, but this results in a significantly more
+ # complicated implementation as opposed to having the client specify the size
+ # up-front (or storing the size along with the digest in every message where
+ # digests are embedded). This does mean that the API leaks some implementation
+ # details of (what we consider to be) a reasonable server implementation, but
+ # we consider this to be a worthwhile tradeoff.
+ #
+ # When a `Digest` is used to refer to a proto message, it always refers to the
+ # message in binary encoded form. To ensure consistent hashing, clients and
+ # servers MUST ensure that they serialize messages according to the following
+ # rules, even if there are alternate valid encodings for the same message:
+ #
+ # * Fields are serialized in tag order.
+ # * There are no unknown fields.
+ # * There are no duplicate fields.
+ # * Fields are serialized according to the default semantics for their type.
+ #
+ # Most protocol buffer implementations will always follow these rules when
+ # serializing, but care should be taken to avoid shortcuts. For instance,
+ # concatenating two messages to merge them may produce duplicate fields.
+ "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.
},
- ],
- "exitCode": 42, # The exit code of the command.
- }
+ "path": "A String", # The full path of the directory relative to the working directory. The path
+ # separator is a forward slash `/`. Since this is a relative path, it MUST
+ # NOT begin with a leading forward slash. The empty string value is allowed,
+ # and it denotes the entire working directory.
+ },
+ ],
+ "stderrDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard error of the action, which
+ # can be retrieved from the
+ # ContentAddressableStorage.
+ # and its hash. The hash algorithm to use is defined by the server.
+ #
+ # The size is considered to be an integral part of the digest and cannot be
+ # separated. That is, even if the `hash` field is correctly specified but
+ # `size_bytes` is not, the server MUST reject the request.
+ #
+ # The reason for including the size in the digest is as follows: in a great
+ # many cases, the server needs to know the size of the blob it is about to work
+ # with prior to starting an operation with it, such as flattening Merkle tree
+ # structures or streaming it to a worker. Technically, the server could
+ # implement a separate metadata store, but this results in a significantly more
+ # complicated implementation as opposed to having the client specify the size
+ # up-front (or storing the size along with the digest in every message where
+ # digests are embedded). This does mean that the API leaks some implementation
+ # details of (what we consider to be) a reasonable server implementation, but
+ # we consider this to be a worthwhile tradeoff.
+ #
+ # When a `Digest` is used to refer to a proto message, it always refers to the
+ # message in binary encoded form. To ensure consistent hashing, clients and
+ # servers MUST ensure that they serialize messages according to the following
+ # rules, even if there are alternate valid encodings for the same message:
+ #
+ # * Fields are serialized in tag order.
+ # * There are no unknown fields.
+ # * There are no duplicate fields.
+ # * Fields are serialized according to the default semantics for their type.
+ #
+ # Most protocol buffer implementations will always follow these rules when
+ # serializing, but care should be taken to avoid shortcuts. For instance,
+ # concatenating two messages to merge them may produce duplicate fields.
+ "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.
+ },
+ "outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. Those
+ # may be links to other output files, or input files, or even absolute paths
+ # outside of the working directory, if the server supports
+ # SymlinkAbsolutePathStrategy.ALLOWED.
+ # For each output file requested in the `output_files` or `output_paths`
+ # field of the Action, if the corresponding file existed after
+ # the action completed, a single entry will be present either in this field,
+ # or in the `output_files` field, if the file was not a symbolic link.
+ #
+ # If an output symbolic link of the same name as listed in `output_files` of
+ # the Command was found, but its target type was not a regular file, the
+ # server will return a FAILED_PRECONDITION.
+ # If the action does not produce the requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ #
+ # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
+ # should still populate this field in addition to `output_symlinks`.
+ { # An `OutputSymlink` is similar to a
+ # Symlink, but it is used as an
+ # output in an `ActionResult`.
+ #
+ # `OutputSymlink` is binary-compatible with `SymlinkNode`.
+ "path": "A String", # The full path of the symlink relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
+ # Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
+ },
+ ],
+ "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.
+ },
+ ],
+ "stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline
+ # stdout unless requested by the client in the
+ # GetActionResultRequest
+ # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
+ # would cause the response to exceed message size limits.
+ "outputFiles": [ # The output files of the action. For each output file requested in the
+ # `output_files` or `output_paths` field of the Action, if the corresponding
+ # file existed after the action completed, a single entry will be present
+ # either in this field, or the `output_file_symlinks` field if the file was
+ # a symbolic link to another file (`output_symlinks` field after v2.1).
+ #
+ # If an output listed in `output_files` was found, but was a directory rather
+ # than a regular file, the server will return a FAILED_PRECONDITION.
+ # If the action does not produce the requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ { # An `OutputFile` is similar to a
+ # FileNode, but it is used as an
+ # output in an `ActionResult`. It allows a full file path rather than
+ # only a name.
+ "isExecutable": True or False, # True if file is executable, false otherwise.
+ "path": "A String", # The full path of the file relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NOT inline
+ # file contents unless requested by the client in the
+ # GetActionResultRequest
+ # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
+ # would cause the response to exceed message size limits.
+ "nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
+ },
+ ],
+ "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.
+ #
+ # 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.
+ },
+ },
+ ],
+ "executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.
+ "workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.
+ "outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
+ "workerStartTimestamp": "A String", # When the worker received the action.
+ "queuedTimestamp": "A String", # When was the action added to the queue.
+ "inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
+ "executionCompletedTimestamp": "A String", # When the worker completed executing the action command.
+ "outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
+ "worker": "A String", # The name of the worker which ran the execution.
+ "executionStartTimestamp": "A String", # When the worker started executing the action command.
+ "inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
+ },
+}
resultsCachePolicy_priority: integer, The priority (relative importance) of this content in the overall cache.
Generally, a lower value means a longer retention time or other advantage,
@@ -989,414 +989,414 @@
An object of the form:
{ # An ActionResult represents the result of an
- # Action being run.
- "executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.
- "outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
- "workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.
- "queuedTimestamp": "A String", # When was the action added to the queue.
- "worker": "A String", # The name of the worker which ran the execution.
- "executionStartTimestamp": "A String", # When the worker started executing the action command.
- "inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
- "workerStartTimestamp": "A String", # When the worker received the action.
- "outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
- "executionCompletedTimestamp": "A String", # When the worker completed executing the action command.
- "inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
- },
- "outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. Those
- # may be links to other output files, or input files, or even absolute paths
- # outside of the working directory, if the server supports
- # SymlinkAbsolutePathStrategy.ALLOWED.
- # For each output file requested in the `output_files` or `output_paths`
- # field of the Action, if the corresponding file existed after
- # the action completed, a single entry will be present either in this field,
- # or in the `output_files` field, if the file was not a symbolic link.
+ # Action being run.
+ "outputSymlinks": [ # New in v2.1: this field will only be populated if the command
+ # `output_paths` field was used, and not the pre v2.1 `output_files` or
+ # `output_directories` fields.
+ # The output paths of the action that are symbolic links to other paths. Those
+ # may be links to other outputs, or inputs, or even absolute paths
+ # outside of the working directory, if the server supports
+ # SymlinkAbsolutePathStrategy.ALLOWED.
+ # A single entry for each output requested in `output_paths`
+ # field of the Action, if the corresponding path existed after
+ # the action completed and was a symbolic link.
+ #
+ # If the action does not produce a requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ { # An `OutputSymlink` is similar to a
+ # Symlink, but it is used as an
+ # output in an `ActionResult`.
#
- # If an output symbolic link of the same name as listed in `output_files` of
- # the Command was found, but its target type was not a regular file, the
- # server will return a FAILED_PRECONDITION.
- # If the action does not produce the requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- #
- # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
- # should still populate this field in addition to `output_symlinks`.
- { # An `OutputSymlink` is similar to a
- # Symlink, but it is used as an
- # output in an `ActionResult`.
- #
- # `OutputSymlink` is binary-compatible with `SymlinkNode`.
- "path": "A String", # The full path of the symlink relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
- # Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- },
- ],
- "stderrDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard error of the action, which
- # can be retrieved from the
- # ContentAddressableStorage.
- # and its hash. The hash algorithm to use is defined by the server.
- #
- # The size is considered to be an integral part of the digest and cannot be
- # separated. That is, even if the `hash` field is correctly specified but
- # `size_bytes` is not, the server MUST reject the request.
- #
- # The reason for including the size in the digest is as follows: in a great
- # many cases, the server needs to know the size of the blob it is about to work
- # with prior to starting an operation with it, such as flattening Merkle tree
- # structures or streaming it to a worker. Technically, the server could
- # implement a separate metadata store, but this results in a significantly more
- # complicated implementation as opposed to having the client specify the size
- # up-front (or storing the size along with the digest in every message where
- # digests are embedded). This does mean that the API leaks some implementation
- # details of (what we consider to be) a reasonable server implementation, but
- # we consider this to be a worthwhile tradeoff.
- #
- # When a `Digest` is used to refer to a proto message, it always refers to the
- # message in binary encoded form. To ensure consistent hashing, clients and
- # servers MUST ensure that they serialize messages according to the following
- # rules, even if there are alternate valid encodings for the same message:
- #
- # * Fields are serialized in tag order.
- # * There are no unknown fields.
- # * There are no duplicate fields.
- # * Fields are serialized according to the default semantics for their type.
- #
- # Most protocol buffer implementations will always follow these rules when
- # serializing, but care should be taken to avoid shortcuts. For instance,
- # concatenating two messages to merge them may produce duplicate fields.
- "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.
- },
- "stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline
- # stdout unless requested by the client in the
- # GetActionResultRequest
- # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
- # would cause the response to exceed message size limits.
- "stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline
- # stderr unless requested by the client in the
- # GetActionResultRequest
- # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
- # would cause the response to exceed message size limits.
- "stdoutDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard output of the action, which
- # can be retrieved from the
- # ContentAddressableStorage.
- # and its hash. The hash algorithm to use is defined by the server.
- #
- # The size is considered to be an integral part of the digest and cannot be
- # separated. That is, even if the `hash` field is correctly specified but
- # `size_bytes` is not, the server MUST reject the request.
- #
- # The reason for including the size in the digest is as follows: in a great
- # many cases, the server needs to know the size of the blob it is about to work
- # with prior to starting an operation with it, such as flattening Merkle tree
- # structures or streaming it to a worker. Technically, the server could
- # implement a separate metadata store, but this results in a significantly more
- # complicated implementation as opposed to having the client specify the size
- # up-front (or storing the size along with the digest in every message where
- # digests are embedded). This does mean that the API leaks some implementation
- # details of (what we consider to be) a reasonable server implementation, but
- # we consider this to be a worthwhile tradeoff.
- #
- # When a `Digest` is used to refer to a proto message, it always refers to the
- # message in binary encoded form. To ensure consistent hashing, clients and
- # servers MUST ensure that they serialize messages according to the following
- # rules, even if there are alternate valid encodings for the same message:
- #
- # * Fields are serialized in tag order.
- # * There are no unknown fields.
- # * There are no duplicate fields.
- # * Fields are serialized according to the default semantics for their type.
- #
- # Most protocol buffer implementations will always follow these rules when
- # serializing, but care should be taken to avoid shortcuts. For instance,
- # concatenating two messages to merge them may produce duplicate fields.
- "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.
- },
- "outputSymlinks": [ # New in v2.1: this field will only be populated if the command
- # `output_paths` field was used, and not the pre v2.1 `output_files` or
- # `output_directories` fields.
- # The output paths of the action that are symbolic links to other paths. Those
- # may be links to other outputs, or inputs, or even absolute paths
- # outside of the working directory, if the server supports
- # SymlinkAbsolutePathStrategy.ALLOWED.
- # A single entry for each output requested in `output_paths`
- # field of the Action, if the corresponding path existed after
- # the action completed and was a symbolic link.
- #
- # If the action does not produce a requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- { # An `OutputSymlink` is similar to a
- # Symlink, but it is used as an
- # output in an `ActionResult`.
- #
- # `OutputSymlink` is binary-compatible with `SymlinkNode`.
- "path": "A String", # The full path of the symlink relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
- # Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- },
- ],
- "outputFiles": [ # The output files of the action. For each output file requested in the
- # `output_files` or `output_paths` field of the Action, if the corresponding
- # file existed after the action completed, a single entry will be present
- # either in this field, or the `output_file_symlinks` field if the file was
- # a symbolic link to another file (`output_symlinks` field after v2.1).
- #
- # If an output listed in `output_files` was found, but was a directory rather
- # than a regular file, the server will return a FAILED_PRECONDITION.
- # If the action does not produce the requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- { # An `OutputFile` is similar to a
- # FileNode, but it is used as an
- # output in an `ActionResult`. It allows a full file path rather than
- # only a name.
- "path": "A String", # The full path of the file relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "isExecutable": True or False, # True if file is executable, false otherwise.
- "nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- #
- # 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.
+ # `OutputSymlink` is binary-compatible with `SymlinkNode`.
+ "path": "A String", # The full path of the symlink relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
+ # Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
},
- "contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NOT inline
- # file contents unless requested by the client in the
- # GetActionResultRequest
- # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
- # would cause the response to exceed message size limits.
- },
- ],
- "outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to other
- # directories. Those may be links to other output directories, or input
- # directories, or even absolute paths outside of the working directory,
- # if the server supports
- # SymlinkAbsolutePathStrategy.ALLOWED.
- # For each output directory requested in the `output_directories` field of
- # the Action, if the directory existed after the action completed, a
- # single entry will be present either in this field, or in the
- # `output_directories` field, if the directory was not a symbolic link.
+ ],
+ "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.
+ },
+ ],
+ "outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to other
+ # directories. Those may be links to other output directories, or input
+ # directories, or even absolute paths outside of the working directory,
+ # if the server supports
+ # SymlinkAbsolutePathStrategy.ALLOWED.
+ # For each output directory requested in the `output_directories` field of
+ # the Action, if the directory existed after the action completed, a
+ # single entry will be present either in this field, or in the
+ # `output_directories` field, if the directory was not a symbolic link.
+ #
+ # If an output of the same name was found, but was a symbolic link to a file
+ # instead of a directory, the server will return a FAILED_PRECONDITION.
+ # If the action does not produce the requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ #
+ # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
+ # should still populate this field in addition to `output_symlinks`.
+ { # An `OutputSymlink` is similar to a
+ # Symlink, but it is used as an
+ # output in an `ActionResult`.
#
- # If an output of the same name was found, but was a symbolic link to a file
- # instead of a directory, the server will return a FAILED_PRECONDITION.
- # If the action does not produce the requested output, then that output
- # will be omitted from the list. The server is free to arrange the output
- # list as desired; clients MUST NOT assume that the output list is sorted.
- #
- # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
- # should still populate this field in addition to `output_symlinks`.
- { # An `OutputSymlink` is similar to a
- # Symlink, but it is used as an
- # output in an `ActionResult`.
- #
- # `OutputSymlink` is binary-compatible with `SymlinkNode`.
- "path": "A String", # The full path of the symlink relative to the working directory, including the
- # filename. The path separator is a forward slash `/`. Since this is a
- # relative path, it MUST NOT begin with a leading forward slash.
- "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
- # Action.
- { # A single property for FileNodes,
- # DirectoryNodes, and
- # SymlinkNodes. The server is
- # responsible for specifying the property `name`s that it accepts. If
- # permitted by the server, the same `name` may occur multiple times.
- "name": "A String", # The property name.
- "value": "A String", # The property value.
- },
- ],
- "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.
- },
- ],
- "outputDirectories": [ # The output directories of the action. For each output directory requested
- # in the `output_directories` or `output_paths` field of the Action, if the
- # corresponding directory existed after the action completed, a single entry
- # will be present in the output list, which will contain the digest of a
- # Tree message containing the
- # directory tree, and the path equal exactly to the corresponding Action
- # output_directories member.
- #
- # As an example, suppose the Action had an output directory `a/b/dir` and the
- # execution produced the following contents in `a/b/dir`: a file named `bar`
- # and a directory named `foo` with an executable file named `baz`. Then,
- # output_directory will contain (hashes shortened for readability):
- #
- # ```json
- # // OutputDirectory proto:
- # {
- # path: "a/b/dir"
- # tree_digest: {
- # hash: "4a73bc9d03...",
- # size: 55
- # }
- # }
- # // Tree proto with hash "4a73bc9d03..." and size 55:
- # {
- # root: {
- # files: [
- # {
- # name: "bar",
- # digest: {
- # hash: "4a73bc9d03...",
- # size: 65534
- # }
- # }
- # ],
- # directories: [
- # {
- # name: "foo",
- # digest: {
- # hash: "4cf2eda940...",
- # size: 43
- # }
- # }
- # ]
- # }
- # children : {
- # // (Directory proto with hash "4cf2eda940..." and size 43)
- # files: [
- # {
- # name: "baz",
- # digest: {
- # hash: "b2c941073e...",
- # size: 1294,
- # },
- # is_executable: true
- # }
- # ]
- # }
- # }
- # ```
- # If an output of the same name as listed in `output_files` of
- # the Command was found in `output_directories`, but was not a directory, the
- # server will return a FAILED_PRECONDITION.
- { # An `OutputDirectory` is the output in an `ActionResult` corresponding to a
- # directory's full contents rather than a single file.
- "path": "A String", # The full path of the directory relative to the working directory. The path
- # separator is a forward slash `/`. Since this is a relative path, it MUST
- # NOT begin with a leading forward slash. The empty string value is allowed,
- # and it denotes the entire working directory.
- "treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the encoded
- # Tree proto containing the
- # directory's contents.
- # and its hash. The hash algorithm to use is defined by the server.
- #
- # The size is considered to be an integral part of the digest and cannot be
- # separated. That is, even if the `hash` field is correctly specified but
- # `size_bytes` is not, the server MUST reject the request.
- #
- # The reason for including the size in the digest is as follows: in a great
- # many cases, the server needs to know the size of the blob it is about to work
- # with prior to starting an operation with it, such as flattening Merkle tree
- # structures or streaming it to a worker. Technically, the server could
- # implement a separate metadata store, but this results in a significantly more
- # complicated implementation as opposed to having the client specify the size
- # up-front (or storing the size along with the digest in every message where
- # digests are embedded). This does mean that the API leaks some implementation
- # details of (what we consider to be) a reasonable server implementation, but
- # we consider this to be a worthwhile tradeoff.
- #
- # When a `Digest` is used to refer to a proto message, it always refers to the
- # message in binary encoded form. To ensure consistent hashing, clients and
- # servers MUST ensure that they serialize messages according to the following
- # rules, even if there are alternate valid encodings for the same message:
- #
- # * Fields are serialized in tag order.
- # * There are no unknown fields.
- # * There are no duplicate fields.
- # * Fields are serialized according to the default semantics for their type.
- #
- # Most protocol buffer implementations will always follow these rules when
- # serializing, but care should be taken to avoid shortcuts. For instance,
- # concatenating two messages to merge them may produce duplicate fields.
- "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.
+ # `OutputSymlink` is binary-compatible with `SymlinkNode`.
+ "path": "A String", # The full path of the symlink relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
+ # Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
},
+ ],
+ "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.
+ },
+ ],
+ "stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline
+ # stderr unless requested by the client in the
+ # GetActionResultRequest
+ # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
+ # would cause the response to exceed message size limits.
+ "stdoutDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard output of the action, which
+ # can be retrieved from the
+ # ContentAddressableStorage.
+ # and its hash. The hash algorithm to use is defined by the server.
+ #
+ # The size is considered to be an integral part of the digest and cannot be
+ # separated. That is, even if the `hash` field is correctly specified but
+ # `size_bytes` is not, the server MUST reject the request.
+ #
+ # The reason for including the size in the digest is as follows: in a great
+ # many cases, the server needs to know the size of the blob it is about to work
+ # with prior to starting an operation with it, such as flattening Merkle tree
+ # structures or streaming it to a worker. Technically, the server could
+ # implement a separate metadata store, but this results in a significantly more
+ # complicated implementation as opposed to having the client specify the size
+ # up-front (or storing the size along with the digest in every message where
+ # digests are embedded). This does mean that the API leaks some implementation
+ # details of (what we consider to be) a reasonable server implementation, but
+ # we consider this to be a worthwhile tradeoff.
+ #
+ # When a `Digest` is used to refer to a proto message, it always refers to the
+ # message in binary encoded form. To ensure consistent hashing, clients and
+ # servers MUST ensure that they serialize messages according to the following
+ # rules, even if there are alternate valid encodings for the same message:
+ #
+ # * Fields are serialized in tag order.
+ # * There are no unknown fields.
+ # * There are no duplicate fields.
+ # * Fields are serialized according to the default semantics for their type.
+ #
+ # Most protocol buffer implementations will always follow these rules when
+ # serializing, but care should be taken to avoid shortcuts. For instance,
+ # concatenating two messages to merge them may produce duplicate fields.
+ "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.
+ },
+ "exitCode": 42, # The exit code of the command.
+ "outputDirectories": [ # The output directories of the action. For each output directory requested
+ # in the `output_directories` or `output_paths` field of the Action, if the
+ # corresponding directory existed after the action completed, a single entry
+ # will be present in the output list, which will contain the digest of a
+ # Tree message containing the
+ # directory tree, and the path equal exactly to the corresponding Action
+ # output_directories member.
+ #
+ # As an example, suppose the Action had an output directory `a/b/dir` and the
+ # execution produced the following contents in `a/b/dir`: a file named `bar`
+ # and a directory named `foo` with an executable file named `baz`. Then,
+ # output_directory will contain (hashes shortened for readability):
+ #
+ # ```json
+ # // OutputDirectory proto:
+ # {
+ # path: "a/b/dir"
+ # tree_digest: {
+ # hash: "4a73bc9d03...",
+ # size: 55
+ # }
+ # }
+ # // Tree proto with hash "4a73bc9d03..." and size 55:
+ # {
+ # root: {
+ # files: [
+ # {
+ # name: "bar",
+ # digest: {
+ # hash: "4a73bc9d03...",
+ # size: 65534
+ # }
+ # }
+ # ],
+ # directories: [
+ # {
+ # name: "foo",
+ # digest: {
+ # hash: "4cf2eda940...",
+ # size: 43
+ # }
+ # }
+ # ]
+ # }
+ # children : {
+ # // (Directory proto with hash "4cf2eda940..." and size 43)
+ # files: [
+ # {
+ # name: "baz",
+ # digest: {
+ # hash: "b2c941073e...",
+ # size: 1294,
+ # },
+ # is_executable: true
+ # }
+ # ]
+ # }
+ # }
+ # ```
+ # If an output of the same name as listed in `output_files` of
+ # the Command was found in `output_directories`, but was not a directory, the
+ # server will return a FAILED_PRECONDITION.
+ { # An `OutputDirectory` is the output in an `ActionResult` corresponding to a
+ # directory's full contents rather than a single file.
+ "treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the encoded
+ # Tree proto containing the
+ # directory's contents.
+ # and its hash. The hash algorithm to use is defined by the server.
+ #
+ # The size is considered to be an integral part of the digest and cannot be
+ # separated. That is, even if the `hash` field is correctly specified but
+ # `size_bytes` is not, the server MUST reject the request.
+ #
+ # The reason for including the size in the digest is as follows: in a great
+ # many cases, the server needs to know the size of the blob it is about to work
+ # with prior to starting an operation with it, such as flattening Merkle tree
+ # structures or streaming it to a worker. Technically, the server could
+ # implement a separate metadata store, but this results in a significantly more
+ # complicated implementation as opposed to having the client specify the size
+ # up-front (or storing the size along with the digest in every message where
+ # digests are embedded). This does mean that the API leaks some implementation
+ # details of (what we consider to be) a reasonable server implementation, but
+ # we consider this to be a worthwhile tradeoff.
+ #
+ # When a `Digest` is used to refer to a proto message, it always refers to the
+ # message in binary encoded form. To ensure consistent hashing, clients and
+ # servers MUST ensure that they serialize messages according to the following
+ # rules, even if there are alternate valid encodings for the same message:
+ #
+ # * Fields are serialized in tag order.
+ # * There are no unknown fields.
+ # * There are no duplicate fields.
+ # * Fields are serialized according to the default semantics for their type.
+ #
+ # Most protocol buffer implementations will always follow these rules when
+ # serializing, but care should be taken to avoid shortcuts. For instance,
+ # concatenating two messages to merge them may produce duplicate fields.
+ "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.
},
- ],
- "exitCode": 42, # The exit code of the command.
- }</pre>
+ "path": "A String", # The full path of the directory relative to the working directory. The path
+ # separator is a forward slash `/`. Since this is a relative path, it MUST
+ # NOT begin with a leading forward slash. The empty string value is allowed,
+ # and it denotes the entire working directory.
+ },
+ ],
+ "stderrDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest for a blob containing the standard error of the action, which
+ # can be retrieved from the
+ # ContentAddressableStorage.
+ # and its hash. The hash algorithm to use is defined by the server.
+ #
+ # The size is considered to be an integral part of the digest and cannot be
+ # separated. That is, even if the `hash` field is correctly specified but
+ # `size_bytes` is not, the server MUST reject the request.
+ #
+ # The reason for including the size in the digest is as follows: in a great
+ # many cases, the server needs to know the size of the blob it is about to work
+ # with prior to starting an operation with it, such as flattening Merkle tree
+ # structures or streaming it to a worker. Technically, the server could
+ # implement a separate metadata store, but this results in a significantly more
+ # complicated implementation as opposed to having the client specify the size
+ # up-front (or storing the size along with the digest in every message where
+ # digests are embedded). This does mean that the API leaks some implementation
+ # details of (what we consider to be) a reasonable server implementation, but
+ # we consider this to be a worthwhile tradeoff.
+ #
+ # When a `Digest` is used to refer to a proto message, it always refers to the
+ # message in binary encoded form. To ensure consistent hashing, clients and
+ # servers MUST ensure that they serialize messages according to the following
+ # rules, even if there are alternate valid encodings for the same message:
+ #
+ # * Fields are serialized in tag order.
+ # * There are no unknown fields.
+ # * There are no duplicate fields.
+ # * Fields are serialized according to the default semantics for their type.
+ #
+ # Most protocol buffer implementations will always follow these rules when
+ # serializing, but care should be taken to avoid shortcuts. For instance,
+ # concatenating two messages to merge them may produce duplicate fields.
+ "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.
+ },
+ "outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. Those
+ # may be links to other output files, or input files, or even absolute paths
+ # outside of the working directory, if the server supports
+ # SymlinkAbsolutePathStrategy.ALLOWED.
+ # For each output file requested in the `output_files` or `output_paths`
+ # field of the Action, if the corresponding file existed after
+ # the action completed, a single entry will be present either in this field,
+ # or in the `output_files` field, if the file was not a symbolic link.
+ #
+ # If an output symbolic link of the same name as listed in `output_files` of
+ # the Command was found, but its target type was not a regular file, the
+ # server will return a FAILED_PRECONDITION.
+ # If the action does not produce the requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ #
+ # DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API
+ # should still populate this field in addition to `output_symlinks`.
+ { # An `OutputSymlink` is similar to a
+ # Symlink, but it is used as an
+ # output in an `ActionResult`.
+ #
+ # `OutputSymlink` is binary-compatible with `SymlinkNode`.
+ "path": "A String", # The full path of the symlink relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the
+ # Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
+ },
+ ],
+ "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.
+ },
+ ],
+ "stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline
+ # stdout unless requested by the client in the
+ # GetActionResultRequest
+ # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
+ # would cause the response to exceed message size limits.
+ "outputFiles": [ # The output files of the action. For each output file requested in the
+ # `output_files` or `output_paths` field of the Action, if the corresponding
+ # file existed after the action completed, a single entry will be present
+ # either in this field, or the `output_file_symlinks` field if the file was
+ # a symbolic link to another file (`output_symlinks` field after v2.1).
+ #
+ # If an output listed in `output_files` was found, but was a directory rather
+ # than a regular file, the server will return a FAILED_PRECONDITION.
+ # If the action does not produce the requested output, then that output
+ # will be omitted from the list. The server is free to arrange the output
+ # list as desired; clients MUST NOT assume that the output list is sorted.
+ { # An `OutputFile` is similar to a
+ # FileNode, but it is used as an
+ # output in an `ActionResult`. It allows a full file path rather than
+ # only a name.
+ "isExecutable": True or False, # True if file is executable, false otherwise.
+ "path": "A String", # The full path of the file relative to the working directory, including the
+ # filename. The path separator is a forward slash `/`. Since this is a
+ # relative path, it MUST NOT begin with a leading forward slash.
+ "contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NOT inline
+ # file contents unless requested by the client in the
+ # GetActionResultRequest
+ # message. The server MAY omit inlining, even if requested, and MUST do so if inlining
+ # would cause the response to exceed message size limits.
+ "nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.
+ { # A single property for FileNodes,
+ # DirectoryNodes, and
+ # SymlinkNodes. The server is
+ # responsible for specifying the property `name`s that it accepts. If
+ # permitted by the server, the same `name` may occur multiple times.
+ "value": "A String", # The property value.
+ "name": "A String", # The property name.
+ },
+ ],
+ "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.
+ #
+ # 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.
+ },
+ },
+ ],
+ "executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.
+ "workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.
+ "outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
+ "workerStartTimestamp": "A String", # When the worker received the action.
+ "queuedTimestamp": "A String", # When was the action added to the queue.
+ "inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
+ "executionCompletedTimestamp": "A String", # When the worker completed executing the action command.
+ "outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
+ "worker": "A String", # The name of the worker which ran the execution.
+ "executionStartTimestamp": "A String", # When the worker started executing the action command.
+ "inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
+ },
+ }</pre>
</div>
</body></html>
\ No newline at end of file