Regen all docs. (#700)

* Stop recursing if discovery == {}

* Generate docs with 'make docs'.
diff --git a/docs/dyn/remotebuildexecution_v2.actionResults.html b/docs/dyn/remotebuildexecution_v2.actionResults.html
new file mode 100644
index 0000000..8de6692
--- /dev/null
+++ b/docs/dyn/remotebuildexecution_v2.actionResults.html
@@ -0,0 +1,1171 @@
+<html><body>
+<style>
+
+body, h1, h2, h3, div, span, p, pre, a {
+  margin: 0;
+  padding: 0;
+  border: 0;
+  font-weight: inherit;
+  font-style: inherit;
+  font-size: 100%;
+  font-family: inherit;
+  vertical-align: baseline;
+}
+
+body {
+  font-size: 13px;
+  padding: 1em;
+}
+
+h1 {
+  font-size: 26px;
+  margin-bottom: 1em;
+}
+
+h2 {
+  font-size: 24px;
+  margin-bottom: 1em;
+}
+
+h3 {
+  font-size: 20px;
+  margin-bottom: 1em;
+  margin-top: 1em;
+}
+
+pre, code {
+  line-height: 1.5;
+  font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Lucida Console', monospace;
+}
+
+pre {
+  margin-top: 0.5em;
+}
+
+h1, h2, h3, p {
+  font-family: Arial, sans serif;
+}
+
+h1, h2, h3 {
+  border-bottom: solid #CCC 1px;
+}
+
+.toc_element {
+  margin-top: 0.5em;
+}
+
+.firstline {
+  margin-left: 2 em;
+}
+
+.method  {
+  margin-top: 1em;
+  border: solid 1px #CCC;
+  padding: 1em;
+  background: #EEE;
+}
+
+.details {
+  font-weight: bold;
+  font-size: 14px;
+}
+
+</style>
+
+<h1><a href="remotebuildexecution_v2.html">Remote Build Execution API</a> . <a href="remotebuildexecution_v2.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>
+<p class="firstline">Retrieve a cached execution result.</p>
+<p class="toc_element">
+  <code><a href="#update">update(instanceName, hash, sizeBytes, body, 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>
+  <pre>Retrieve a cached execution result.
+
+Implementations SHOULD ensure that any blobs referenced from the
+ContentAddressableStorage
+are available at the time of returning the
+ActionResult and will be
+for some period of time afterwards. The TTLs of the referenced blobs SHOULD be increased
+if necessary and applicable.
+
+Errors:
+
+* `NOT_FOUND`: The requested `ActionResult` is not in the cache.
+
+Args:
+  instanceName: string, The instance of the execution system to operate against. A server may
+support multiple instances of the execution system (with their own workers,
+storage, caches, etc.). The server MAY require use of this field to select
+between them in an implementation-defined fashion, otherwise it can be
+omitted. (required)
+  hash: string, The hash. In the case of SHA-256, it will always be a lowercase hex string
+exactly 64 characters long. (required)
+  sizeBytes: string, The size of the blob, in bytes. (required)
+  inlineStdout: boolean, A hint to the server to request inlining stdout 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
+ActionResult message.
+  x__xgafv: string, V1 error format.
+    Allowed values
+      1 - v1 error format
+      2 - v2 error format
+
+Returns:
+  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` 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 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.
+        { # 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.
+          "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, but servers
+          # SHOULD use SHA-256.
+          #
+          # The size is considered to be an integral part of the digest and cannot be
+          # separated. That is, even if the `hash` field is correctly specified but
+          # `size_bytes` is not, the server MUST reject the request.
+          #
+          # The reason for including the size in the digest is as follows: in a great
+          # many cases, the server needs to know the size of the blob it is about to work
+          # with prior to starting an operation with it, such as flattening Merkle tree
+          # structures or streaming it to a worker. Technically, the server could
+          # implement a separate metadata store, but this results in a significantly more
+          # complicated implementation as opposed to having the client specify the size
+          # up-front (or storing the size along with the digest in every message where
+          # digests are embedded). This does mean that the API leaks some implementation
+          # details of (what we consider to be) a reasonable server implementation, but
+          # we consider this to be a worthwhile tradeoff.
+          #
+          # When a `Digest` is used to refer to a proto message, it always refers to the
+          # message in binary encoded form. To ensure consistent hashing, clients and
+          # servers MUST ensure that they serialize messages according to the following
+          # rules, even if there are alternate valid encodings for the same message:
+          #
+          # * Fields are serialized in tag order.
+          # * There are no unknown fields.
+          # * There are no duplicate fields.
+          # * Fields are serialized according to the default semantics for their type.
+          #
+          # Most protocol buffer implementations will always follow these rules when
+          # serializing, but care should be taken to avoid shortcuts. For instance,
+          # concatenating two messages to merge them may produce duplicate fields.
+        "sizeBytes": "A String", # The size of the blob, in bytes.
+        "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+            # exactly 64 characters long.
+      },
+      "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, but servers
+          # SHOULD use SHA-256.
+          #
+          # The size is considered to be an integral part of the digest and cannot be
+          # separated. That is, even if the `hash` field is correctly specified but
+          # `size_bytes` is not, the server MUST reject the request.
+          #
+          # The reason for including the size in the digest is as follows: in a great
+          # many cases, the server needs to know the size of the blob it is about to work
+          # with prior to starting an operation with it, such as flattening Merkle tree
+          # structures or streaming it to a worker. Technically, the server could
+          # implement a separate metadata store, but this results in a significantly more
+          # complicated implementation as opposed to having the client specify the size
+          # up-front (or storing the size along with the digest in every message where
+          # digests are embedded). This does mean that the API leaks some implementation
+          # details of (what we consider to be) a reasonable server implementation, but
+          # we consider this to be a worthwhile tradeoff.
+          #
+          # When a `Digest` is used to refer to a proto message, it always refers to the
+          # message in binary encoded form. To ensure consistent hashing, clients and
+          # servers MUST ensure that they serialize messages according to the following
+          # rules, even if there are alternate valid encodings for the same message:
+          #
+          # * Fields are serialized in tag order.
+          # * There are no unknown fields.
+          # * There are no duplicate fields.
+          # * Fields are serialized according to the default semantics for their type.
+          #
+          # Most protocol buffer implementations will always follow these rules when
+          # serializing, but care should be taken to avoid shortcuts. For instance,
+          # concatenating two messages to merge them may produce duplicate fields.
+        "sizeBytes": "A String", # The size of the blob, in bytes.
+        "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+            # exactly 64 characters long.
+      },
+      "outputFiles": [ # The output files of the action. For each output file requested in the
+          # `output_files` 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.
+          #
+          # If an output of the same name 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.
+          "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.
+          "digest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the file's content.
+              # and its hash. The hash algorithm to use is defined by the server, but servers
+              # SHOULD use SHA-256.
+              #
+              # The size is considered to be an integral part of the digest and cannot be
+              # separated. That is, even if the `hash` field is correctly specified but
+              # `size_bytes` is not, the server MUST reject the request.
+              #
+              # The reason for including the size in the digest is as follows: in a great
+              # many cases, the server needs to know the size of the blob it is about to work
+              # with prior to starting an operation with it, such as flattening Merkle tree
+              # structures or streaming it to a worker. Technically, the server could
+              # implement a separate metadata store, but this results in a significantly more
+              # complicated implementation as opposed to having the client specify the size
+              # up-front (or storing the size along with the digest in every message where
+              # digests are embedded). This does mean that the API leaks some implementation
+              # details of (what we consider to be) a reasonable server implementation, but
+              # we consider this to be a worthwhile tradeoff.
+              #
+              # When a `Digest` is used to refer to a proto message, it always refers to the
+              # message in binary encoded form. To ensure consistent hashing, clients and
+              # servers MUST ensure that they serialize messages according to the following
+              # rules, even if there are alternate valid encodings for the same message:
+              #
+              # * Fields are serialized in tag order.
+              # * There are no unknown fields.
+              # * There are no duplicate fields.
+              # * Fields are serialized according to the default semantics for their type.
+              #
+              # Most protocol buffer implementations will always follow these rules when
+              # serializing, but care should be taken to avoid shortcuts. For instance,
+              # concatenating two messages to merge them may produce duplicate fields.
+            "sizeBytes": "A String", # The size of the blob, in bytes.
+            "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+                # exactly 64 characters long.
+          },
+        },
+      ],
+      "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.
+        { # 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.
+          "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` 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 was found, 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, but servers
+              # SHOULD use SHA-256.
+              #
+              # The size is considered to be an integral part of the digest and cannot be
+              # separated. That is, even if the `hash` field is correctly specified but
+              # `size_bytes` is not, the server MUST reject the request.
+              #
+              # The reason for including the size in the digest is as follows: in a great
+              # many cases, the server needs to know the size of the blob it is about to work
+              # with prior to starting an operation with it, such as flattening Merkle tree
+              # structures or streaming it to a worker. Technically, the server could
+              # implement a separate metadata store, but this results in a significantly more
+              # complicated implementation as opposed to having the client specify the size
+              # up-front (or storing the size along with the digest in every message where
+              # digests are embedded). This does mean that the API leaks some implementation
+              # details of (what we consider to be) a reasonable server implementation, but
+              # we consider this to be a worthwhile tradeoff.
+              #
+              # When a `Digest` is used to refer to a proto message, it always refers to the
+              # message in binary encoded form. To ensure consistent hashing, clients and
+              # servers MUST ensure that they serialize messages according to the following
+              # rules, even if there are alternate valid encodings for the same message:
+              #
+              # * Fields are serialized in tag order.
+              # * There are no unknown fields.
+              # * There are no duplicate fields.
+              # * Fields are serialized according to the default semantics for their type.
+              #
+              # Most protocol buffer implementations will always follow these rules when
+              # serializing, but care should be taken to avoid shortcuts. For instance,
+              # concatenating two messages to merge them may produce duplicate fields.
+            "sizeBytes": "A String", # The size of the blob, in bytes.
+            "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+                # exactly 64 characters long.
+          },
+        },
+      ],
+      "exitCode": 42, # The exit code of the command.
+    }</pre>
+</div>
+
+<div class="method">
+    <code class="details" id="update">update(instanceName, hash, sizeBytes, body, resultsCachePolicy_priority=None, x__xgafv=None)</code>
+  <pre>Upload a new execution result.
+
+In order to allow the server to perform access control based on the type of
+action, and to assist with client debugging, the client MUST first upload
+the Action that produced the
+result, along with its
+Command, into the
+`ContentAddressableStorage`.
+
+Errors:
+
+* `INVALID_ARGUMENT`: One or more arguments are invalid.
+* `FAILED_PRECONDITION`: One or more errors occurred in updating the
+  action result, such as a missing command or action.
+* `RESOURCE_EXHAUSTED`: There is insufficient storage space to add the
+  entry to the cache.
+
+Args:
+  instanceName: string, The instance of the execution system to operate against. A server may
+support multiple instances of the execution system (with their own workers,
+storage, caches, etc.). The server MAY require use of this field to select
+between them in an implementation-defined fashion, otherwise it can be
+omitted. (required)
+  hash: string, The hash. In the case of SHA-256, it will always be a lowercase hex string
+exactly 64 characters long. (required)
+  sizeBytes: string, The size of the blob, in bytes. (required)
+  body: object, The request body. (required)
+    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` 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 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.
+      { # 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.
+        "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, but servers
+        # SHOULD use SHA-256.
+        #
+        # The size is considered to be an integral part of the digest and cannot be
+        # separated. That is, even if the `hash` field is correctly specified but
+        # `size_bytes` is not, the server MUST reject the request.
+        #
+        # The reason for including the size in the digest is as follows: in a great
+        # many cases, the server needs to know the size of the blob it is about to work
+        # with prior to starting an operation with it, such as flattening Merkle tree
+        # structures or streaming it to a worker. Technically, the server could
+        # implement a separate metadata store, but this results in a significantly more
+        # complicated implementation as opposed to having the client specify the size
+        # up-front (or storing the size along with the digest in every message where
+        # digests are embedded). This does mean that the API leaks some implementation
+        # details of (what we consider to be) a reasonable server implementation, but
+        # we consider this to be a worthwhile tradeoff.
+        #
+        # When a `Digest` is used to refer to a proto message, it always refers to the
+        # message in binary encoded form. To ensure consistent hashing, clients and
+        # servers MUST ensure that they serialize messages according to the following
+        # rules, even if there are alternate valid encodings for the same message:
+        #
+        # * Fields are serialized in tag order.
+        # * There are no unknown fields.
+        # * There are no duplicate fields.
+        # * Fields are serialized according to the default semantics for their type.
+        #
+        # Most protocol buffer implementations will always follow these rules when
+        # serializing, but care should be taken to avoid shortcuts. For instance,
+        # concatenating two messages to merge them may produce duplicate fields.
+      "sizeBytes": "A String", # The size of the blob, in bytes.
+      "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+          # exactly 64 characters long.
+    },
+    "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, but servers
+        # SHOULD use SHA-256.
+        #
+        # The size is considered to be an integral part of the digest and cannot be
+        # separated. That is, even if the `hash` field is correctly specified but
+        # `size_bytes` is not, the server MUST reject the request.
+        #
+        # The reason for including the size in the digest is as follows: in a great
+        # many cases, the server needs to know the size of the blob it is about to work
+        # with prior to starting an operation with it, such as flattening Merkle tree
+        # structures or streaming it to a worker. Technically, the server could
+        # implement a separate metadata store, but this results in a significantly more
+        # complicated implementation as opposed to having the client specify the size
+        # up-front (or storing the size along with the digest in every message where
+        # digests are embedded). This does mean that the API leaks some implementation
+        # details of (what we consider to be) a reasonable server implementation, but
+        # we consider this to be a worthwhile tradeoff.
+        #
+        # When a `Digest` is used to refer to a proto message, it always refers to the
+        # message in binary encoded form. To ensure consistent hashing, clients and
+        # servers MUST ensure that they serialize messages according to the following
+        # rules, even if there are alternate valid encodings for the same message:
+        #
+        # * Fields are serialized in tag order.
+        # * There are no unknown fields.
+        # * There are no duplicate fields.
+        # * Fields are serialized according to the default semantics for their type.
+        #
+        # Most protocol buffer implementations will always follow these rules when
+        # serializing, but care should be taken to avoid shortcuts. For instance,
+        # concatenating two messages to merge them may produce duplicate fields.
+      "sizeBytes": "A String", # The size of the blob, in bytes.
+      "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+          # exactly 64 characters long.
+    },
+    "outputFiles": [ # The output files of the action. For each output file requested in the
+        # `output_files` 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.
+        # 
+        # If an output of the same name 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.
+        "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.
+        "digest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the file's content.
+            # and its hash. The hash algorithm to use is defined by the server, but servers
+            # SHOULD use SHA-256.
+            #
+            # The size is considered to be an integral part of the digest and cannot be
+            # separated. That is, even if the `hash` field is correctly specified but
+            # `size_bytes` is not, the server MUST reject the request.
+            #
+            # The reason for including the size in the digest is as follows: in a great
+            # many cases, the server needs to know the size of the blob it is about to work
+            # with prior to starting an operation with it, such as flattening Merkle tree
+            # structures or streaming it to a worker. Technically, the server could
+            # implement a separate metadata store, but this results in a significantly more
+            # complicated implementation as opposed to having the client specify the size
+            # up-front (or storing the size along with the digest in every message where
+            # digests are embedded). This does mean that the API leaks some implementation
+            # details of (what we consider to be) a reasonable server implementation, but
+            # we consider this to be a worthwhile tradeoff.
+            #
+            # When a `Digest` is used to refer to a proto message, it always refers to the
+            # message in binary encoded form. To ensure consistent hashing, clients and
+            # servers MUST ensure that they serialize messages according to the following
+            # rules, even if there are alternate valid encodings for the same message:
+            #
+            # * Fields are serialized in tag order.
+            # * There are no unknown fields.
+            # * There are no duplicate fields.
+            # * Fields are serialized according to the default semantics for their type.
+            #
+            # Most protocol buffer implementations will always follow these rules when
+            # serializing, but care should be taken to avoid shortcuts. For instance,
+            # concatenating two messages to merge them may produce duplicate fields.
+          "sizeBytes": "A String", # The size of the blob, in bytes.
+          "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+              # exactly 64 characters long.
+        },
+      },
+    ],
+    "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.
+      { # 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.
+        "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` 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 was found, 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, but servers
+            # SHOULD use SHA-256.
+            #
+            # The size is considered to be an integral part of the digest and cannot be
+            # separated. That is, even if the `hash` field is correctly specified but
+            # `size_bytes` is not, the server MUST reject the request.
+            #
+            # The reason for including the size in the digest is as follows: in a great
+            # many cases, the server needs to know the size of the blob it is about to work
+            # with prior to starting an operation with it, such as flattening Merkle tree
+            # structures or streaming it to a worker. Technically, the server could
+            # implement a separate metadata store, but this results in a significantly more
+            # complicated implementation as opposed to having the client specify the size
+            # up-front (or storing the size along with the digest in every message where
+            # digests are embedded). This does mean that the API leaks some implementation
+            # details of (what we consider to be) a reasonable server implementation, but
+            # we consider this to be a worthwhile tradeoff.
+            #
+            # When a `Digest` is used to refer to a proto message, it always refers to the
+            # message in binary encoded form. To ensure consistent hashing, clients and
+            # servers MUST ensure that they serialize messages according to the following
+            # rules, even if there are alternate valid encodings for the same message:
+            #
+            # * Fields are serialized in tag order.
+            # * There are no unknown fields.
+            # * There are no duplicate fields.
+            # * Fields are serialized according to the default semantics for their type.
+            #
+            # Most protocol buffer implementations will always follow these rules when
+            # serializing, but care should be taken to avoid shortcuts. For instance,
+            # concatenating two messages to merge them may produce duplicate fields.
+          "sizeBytes": "A String", # The size of the blob, in bytes.
+          "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+              # exactly 64 characters long.
+        },
+      },
+    ],
+    "exitCode": 42, # The exit code of the command.
+  }
+
+  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,
+but the interpretation of a given value is server-dependent. A priority of
+0 means a *default* value, decided by the server.
+
+The particular semantics of this field is up to the server. In particular,
+every server will have their own supported range of priorities, and will
+decide how these map into retention/eviction policy.
+  x__xgafv: string, V1 error format.
+    Allowed values
+      1 - v1 error format
+      2 - v2 error format
+
+Returns:
+  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` 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 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.
+        { # 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.
+          "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, but servers
+          # SHOULD use SHA-256.
+          #
+          # The size is considered to be an integral part of the digest and cannot be
+          # separated. That is, even if the `hash` field is correctly specified but
+          # `size_bytes` is not, the server MUST reject the request.
+          #
+          # The reason for including the size in the digest is as follows: in a great
+          # many cases, the server needs to know the size of the blob it is about to work
+          # with prior to starting an operation with it, such as flattening Merkle tree
+          # structures or streaming it to a worker. Technically, the server could
+          # implement a separate metadata store, but this results in a significantly more
+          # complicated implementation as opposed to having the client specify the size
+          # up-front (or storing the size along with the digest in every message where
+          # digests are embedded). This does mean that the API leaks some implementation
+          # details of (what we consider to be) a reasonable server implementation, but
+          # we consider this to be a worthwhile tradeoff.
+          #
+          # When a `Digest` is used to refer to a proto message, it always refers to the
+          # message in binary encoded form. To ensure consistent hashing, clients and
+          # servers MUST ensure that they serialize messages according to the following
+          # rules, even if there are alternate valid encodings for the same message:
+          #
+          # * Fields are serialized in tag order.
+          # * There are no unknown fields.
+          # * There are no duplicate fields.
+          # * Fields are serialized according to the default semantics for their type.
+          #
+          # Most protocol buffer implementations will always follow these rules when
+          # serializing, but care should be taken to avoid shortcuts. For instance,
+          # concatenating two messages to merge them may produce duplicate fields.
+        "sizeBytes": "A String", # The size of the blob, in bytes.
+        "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+            # exactly 64 characters long.
+      },
+      "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, but servers
+          # SHOULD use SHA-256.
+          #
+          # The size is considered to be an integral part of the digest and cannot be
+          # separated. That is, even if the `hash` field is correctly specified but
+          # `size_bytes` is not, the server MUST reject the request.
+          #
+          # The reason for including the size in the digest is as follows: in a great
+          # many cases, the server needs to know the size of the blob it is about to work
+          # with prior to starting an operation with it, such as flattening Merkle tree
+          # structures or streaming it to a worker. Technically, the server could
+          # implement a separate metadata store, but this results in a significantly more
+          # complicated implementation as opposed to having the client specify the size
+          # up-front (or storing the size along with the digest in every message where
+          # digests are embedded). This does mean that the API leaks some implementation
+          # details of (what we consider to be) a reasonable server implementation, but
+          # we consider this to be a worthwhile tradeoff.
+          #
+          # When a `Digest` is used to refer to a proto message, it always refers to the
+          # message in binary encoded form. To ensure consistent hashing, clients and
+          # servers MUST ensure that they serialize messages according to the following
+          # rules, even if there are alternate valid encodings for the same message:
+          #
+          # * Fields are serialized in tag order.
+          # * There are no unknown fields.
+          # * There are no duplicate fields.
+          # * Fields are serialized according to the default semantics for their type.
+          #
+          # Most protocol buffer implementations will always follow these rules when
+          # serializing, but care should be taken to avoid shortcuts. For instance,
+          # concatenating two messages to merge them may produce duplicate fields.
+        "sizeBytes": "A String", # The size of the blob, in bytes.
+        "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+            # exactly 64 characters long.
+      },
+      "outputFiles": [ # The output files of the action. For each output file requested in the
+          # `output_files` 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.
+          #
+          # If an output of the same name 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.
+          "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.
+          "digest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the file's content.
+              # and its hash. The hash algorithm to use is defined by the server, but servers
+              # SHOULD use SHA-256.
+              #
+              # The size is considered to be an integral part of the digest and cannot be
+              # separated. That is, even if the `hash` field is correctly specified but
+              # `size_bytes` is not, the server MUST reject the request.
+              #
+              # The reason for including the size in the digest is as follows: in a great
+              # many cases, the server needs to know the size of the blob it is about to work
+              # with prior to starting an operation with it, such as flattening Merkle tree
+              # structures or streaming it to a worker. Technically, the server could
+              # implement a separate metadata store, but this results in a significantly more
+              # complicated implementation as opposed to having the client specify the size
+              # up-front (or storing the size along with the digest in every message where
+              # digests are embedded). This does mean that the API leaks some implementation
+              # details of (what we consider to be) a reasonable server implementation, but
+              # we consider this to be a worthwhile tradeoff.
+              #
+              # When a `Digest` is used to refer to a proto message, it always refers to the
+              # message in binary encoded form. To ensure consistent hashing, clients and
+              # servers MUST ensure that they serialize messages according to the following
+              # rules, even if there are alternate valid encodings for the same message:
+              #
+              # * Fields are serialized in tag order.
+              # * There are no unknown fields.
+              # * There are no duplicate fields.
+              # * Fields are serialized according to the default semantics for their type.
+              #
+              # Most protocol buffer implementations will always follow these rules when
+              # serializing, but care should be taken to avoid shortcuts. For instance,
+              # concatenating two messages to merge them may produce duplicate fields.
+            "sizeBytes": "A String", # The size of the blob, in bytes.
+            "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+                # exactly 64 characters long.
+          },
+        },
+      ],
+      "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.
+        { # 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.
+          "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` 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 was found, 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, but servers
+              # SHOULD use SHA-256.
+              #
+              # The size is considered to be an integral part of the digest and cannot be
+              # separated. That is, even if the `hash` field is correctly specified but
+              # `size_bytes` is not, the server MUST reject the request.
+              #
+              # The reason for including the size in the digest is as follows: in a great
+              # many cases, the server needs to know the size of the blob it is about to work
+              # with prior to starting an operation with it, such as flattening Merkle tree
+              # structures or streaming it to a worker. Technically, the server could
+              # implement a separate metadata store, but this results in a significantly more
+              # complicated implementation as opposed to having the client specify the size
+              # up-front (or storing the size along with the digest in every message where
+              # digests are embedded). This does mean that the API leaks some implementation
+              # details of (what we consider to be) a reasonable server implementation, but
+              # we consider this to be a worthwhile tradeoff.
+              #
+              # When a `Digest` is used to refer to a proto message, it always refers to the
+              # message in binary encoded form. To ensure consistent hashing, clients and
+              # servers MUST ensure that they serialize messages according to the following
+              # rules, even if there are alternate valid encodings for the same message:
+              #
+              # * Fields are serialized in tag order.
+              # * There are no unknown fields.
+              # * There are no duplicate fields.
+              # * Fields are serialized according to the default semantics for their type.
+              #
+              # Most protocol buffer implementations will always follow these rules when
+              # serializing, but care should be taken to avoid shortcuts. For instance,
+              # concatenating two messages to merge them may produce duplicate fields.
+            "sizeBytes": "A String", # The size of the blob, in bytes.
+            "hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string
+                # exactly 64 characters long.
+          },
+        },
+      ],
+      "exitCode": 42, # The exit code of the command.
+    }</pre>
+</div>
+
+</body></html>
\ No newline at end of file