Blame - docs/dyn/remotebuildexecution_v2.actionResults.html - platform/external/python/google-api-python-client

blob: 2caea16711a85d0956c63981e82063b4e76a3586 [file] [log] [blame]

Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	1	<html><body>
				2	<style>
				3
				4	body, h1, h2, h3, div, span, p, pre, a {
				5	margin: 0;
				6	padding: 0;
				7	border: 0;
				8	font-weight: inherit;
				9	font-style: inherit;
				10	font-size: 100%;
				11	font-family: inherit;
				12	vertical-align: baseline;
				13	}
				14
				15	body {
				16	font-size: 13px;
				17	padding: 1em;
				18	}
				19
				20	h1 {
				21	font-size: 26px;
				22	margin-bottom: 1em;
				23	}
				24
				25	h2 {
				26	font-size: 24px;
				27	margin-bottom: 1em;
				28	}
				29
				30	h3 {
				31	font-size: 20px;
				32	margin-bottom: 1em;
				33	margin-top: 1em;
				34	}
				35
				36	pre, code {
				37	line-height: 1.5;
				38	font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Lucida Console', monospace;
				39	}
				40
				41	pre {
				42	margin-top: 0.5em;
				43	}
				44
				45	h1, h2, h3, p {
				46	font-family: Arial, sans serif;
				47	}
				48
				49	h1, h2, h3 {
				50	border-bottom: solid #CCC 1px;
				51	}
				52
				53	.toc_element {
				54	margin-top: 0.5em;
				55	}
				56
				57	.firstline {
				58	margin-left: 2 em;
				59	}
				60
				61	.method {
				62	margin-top: 1em;
				63	border: solid 1px #CCC;
				64	padding: 1em;
				65	background: #EEE;
				66	}
				67
				68	.details {
				69	font-weight: bold;
				70	font-size: 14px;
				71	}
				72
				73	</style>
				74
				75	<h1><a href="remotebuildexecution_v2.html">Remote Build Execution API</a> . <a href="remotebuildexecution_v2.actionResults.html">actionResults</a></h1>
				76	<h2>Instance Methods</h2>
				77	<p class="toc_element">
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	78	<code><a href="#close">close()</a></code></p>
				79	<p class="firstline">Close httplib2 connections.</p>
				80	<p class="toc_element">
				81	<code><a href="#get">get(instanceName, hash, sizeBytes, inlineOutputFiles=None, inlineStdout=None, inlineStderr=None, x__xgafv=None)</a></code></p>
				82	<p class="firstline">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.</p>
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	83	<p class="toc_element">
Dan O'Meara	dd49464	2020-05-01 07:42:23 -0700	[diff] [blame]	84	<code><a href="#update">update(instanceName, hash, sizeBytes, body=None, resultsCachePolicy_priority=None, x__xgafv=None)</a></code></p>
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	85	<p class="firstline">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.</p>
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	86	<h3>Method Details</h3>
				87	<div class="method">
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	88	<code class="details" id="close">close()</code>
				89	<pre>Close httplib2 connections.</pre>
				90	</div>
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	91
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	92	<div class="method">
				93	<code class="details" id="get">get(instanceName, hash, sizeBytes, inlineOutputFiles=None, inlineStdout=None, inlineStderr=None, x__xgafv=None)</code>
				94	<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.
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	95
				96	Args:
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	97	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)
				98	hash: string, The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long. (required)
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	99	sizeBytes: string, The size of the blob, in bytes. (required)
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	100	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)
				101	inlineStdout: boolean, A hint to the server to request inlining stdout in the ActionResult message.
				102	inlineStderr: boolean, A hint to the server to request inlining stderr in the ActionResult message.
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	103	x__xgafv: string, V1 error format.
				104	Allowed values
				105	1 - v1 error format
				106	2 - v2 error format
				107
				108	Returns:
				109	An object of the form:
				110
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	111	{ # An ActionResult represents the result of an Action being run.
				112	"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`.
				113	{ # An `OutputSymlink` is similar to a Symlink, but it is used as an output in an `ActionResult`. `OutputSymlink` is binary-compatible with `SymlinkNode`.
				114	"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.
				115	"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the Action.
				116	{ # 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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	117	"value": "A String", # The property value.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	118	"name": "A String", # The property name.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	119	},
				120	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	121	"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.
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	122	},
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	123	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	124	"stderrDigest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest for a blob containing the standard error of the action, which can be retrieved from the ContentAddressableStorage.
				125	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				126	"sizeBytes": "A String", # The size of the blob, in bytes.
				127	},
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	128	"executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	129	"inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
				130	"inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	131	"workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	132	"outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
				133	"executionCompletedTimestamp": "A String", # When the worker completed executing the action command.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	134	"workerStartTimestamp": "A String", # When the worker received the action.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	135	"outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	136	"queuedTimestamp": "A String", # When was the action added to the queue.
				137	"worker": "A String", # The name of the worker which ran the execution.
				138	"executionStartTimestamp": "A String", # When the worker started executing the action command.
Bu Sun Kim	6502091	2020-05-20 12:08:20 -0700	[diff] [blame]	139	},
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	140	"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.
				141	{ # An `OutputSymlink` is similar to a Symlink, but it is used as an output in an `ActionResult`. `OutputSymlink` is binary-compatible with `SymlinkNode`.
				142	"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.
				143	"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the Action.
				144	{ # 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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	145	"value": "A String", # The property value.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	146	"name": "A String", # The property name.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	147	},
				148	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	149	"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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	150	},
				151	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	152	"stdoutDigest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest for a blob containing the standard output of the action, which can be retrieved from the ContentAddressableStorage.
				153	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				154	"sizeBytes": "A String", # The size of the blob, in bytes.
				155	},
				156	"exitCode": 42, # The exit code of the command.
				157	"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.
				158	"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.
				159	{ # 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.
				160	"isExecutable": True or False, # True if file is executable, false otherwise.
				161	"nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.
				162	{ # 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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	163	"value": "A String", # The property value.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	164	"name": "A String", # The property name.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	165	},
				166	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	167	"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.
				168	"digest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest of the file's content.
				169	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				170	"sizeBytes": "A String", # The size of the blob, in bytes.
				171	},
				172	"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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	173	},
				174	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	175	"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.
				176	{ # An `OutputDirectory` is the output in an `ActionResult` corresponding to a directory's full contents rather than a single file.
				177	"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.
				178	"treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest of the encoded Tree proto containing the directory's contents.
				179	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				180	"sizeBytes": "A String", # The size of the blob, in bytes.
				181	},
				182	},
				183	],
				184	"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`.
				185	{ # An `OutputSymlink` is similar to a Symlink, but it is used as an output in an `ActionResult`. `OutputSymlink` is binary-compatible with `SymlinkNode`.
				186	"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.
				187	"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the Action.
				188	{ # 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.
				189	"value": "A String", # The property value.
				190	"name": "A String", # The property name.
				191	},
				192	],
				193	"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.
				194	},
				195	],
				196	"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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	197	}</pre>
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	198	</div>
				199
				200	<div class="method">
Dan O'Meara	dd49464	2020-05-01 07:42:23 -0700	[diff] [blame]	201	<code class="details" id="update">update(instanceName, hash, sizeBytes, body=None, resultsCachePolicy_priority=None, x__xgafv=None)</code>
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	202	<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.
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	203
				204	Args:
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	205	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)
				206	hash: string, The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long. (required)
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	207	sizeBytes: string, The size of the blob, in bytes. (required)
Dan O'Meara	dd49464	2020-05-01 07:42:23 -0700	[diff] [blame]	208	body: object, The request body.
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	209	The object takes the form of:
				210
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	211	{ # An ActionResult represents the result of an Action being run.
				212	"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`.
				213	{ # An `OutputSymlink` is similar to a Symlink, but it is used as an output in an `ActionResult`. `OutputSymlink` is binary-compatible with `SymlinkNode`.
				214	"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.
				215	"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the Action.
				216	{ # 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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	217	"value": "A String", # The property value.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	218	"name": "A String", # The property name.
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	219	},
Bu Sun Kim	6502091	2020-05-20 12:08:20 -0700	[diff] [blame]	220	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	221	"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.
Bu Sun Kim	6502091	2020-05-20 12:08:20 -0700	[diff] [blame]	222	},
				223	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	224	"stderrDigest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest for a blob containing the standard error of the action, which can be retrieved from the ContentAddressableStorage.
				225	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				226	"sizeBytes": "A String", # The size of the blob, in bytes.
				227	},
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	228	"executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	229	"inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
				230	"inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	231	"workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	232	"outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
				233	"executionCompletedTimestamp": "A String", # When the worker completed executing the action command.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	234	"workerStartTimestamp": "A String", # When the worker received the action.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	235	"outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	236	"queuedTimestamp": "A String", # When was the action added to the queue.
				237	"worker": "A String", # The name of the worker which ran the execution.
				238	"executionStartTimestamp": "A String", # When the worker started executing the action command.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	239	},
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	240	"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.
				241	{ # An `OutputSymlink` is similar to a Symlink, but it is used as an output in an `ActionResult`. `OutputSymlink` is binary-compatible with `SymlinkNode`.
				242	"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.
				243	"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the Action.
				244	{ # 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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	245	"value": "A String", # The property value.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	246	"name": "A String", # The property name.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	247	},
				248	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	249	"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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	250	},
				251	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	252	"stdoutDigest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest for a blob containing the standard output of the action, which can be retrieved from the ContentAddressableStorage.
				253	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				254	"sizeBytes": "A String", # The size of the blob, in bytes.
				255	},
				256	"exitCode": 42, # The exit code of the command.
				257	"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.
				258	"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.
				259	{ # 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.
				260	"isExecutable": True or False, # True if file is executable, false otherwise.
				261	"nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.
				262	{ # 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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	263	"value": "A String", # The property value.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	264	"name": "A String", # The property name.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	265	},
				266	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	267	"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.
				268	"digest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest of the file's content.
				269	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				270	"sizeBytes": "A String", # The size of the blob, in bytes.
				271	},
				272	"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.
Bu Sun Kim	6502091	2020-05-20 12:08:20 -0700	[diff] [blame]	273	},
				274	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	275	"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.
				276	{ # An `OutputDirectory` is the output in an `ActionResult` corresponding to a directory's full contents rather than a single file.
				277	"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.
				278	"treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest of the encoded Tree proto containing the directory's contents.
				279	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				280	"sizeBytes": "A String", # The size of the blob, in bytes.
				281	},
				282	},
				283	],
				284	"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`.
				285	{ # An `OutputSymlink` is similar to a Symlink, but it is used as an output in an `ActionResult`. `OutputSymlink` is binary-compatible with `SymlinkNode`.
				286	"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.
				287	"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the Action.
				288	{ # 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.
				289	"value": "A String", # The property value.
				290	"name": "A String", # The property name.
				291	},
				292	],
				293	"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.
				294	},
				295	],
				296	"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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	297	}
				298
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	299	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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	300	x__xgafv: string, V1 error format.
				301	Allowed values
				302	1 - v1 error format
				303	2 - v2 error format
				304
				305	Returns:
				306	An object of the form:
				307
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	308	{ # An ActionResult represents the result of an Action being run.
				309	"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`.
				310	{ # An `OutputSymlink` is similar to a Symlink, but it is used as an output in an `ActionResult`. `OutputSymlink` is binary-compatible with `SymlinkNode`.
				311	"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.
				312	"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the Action.
				313	{ # 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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	314	"value": "A String", # The property value.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	315	"name": "A String", # The property name.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	316	},
				317	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	318	"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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	319	},
				320	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	321	"stderrDigest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest for a blob containing the standard error of the action, which can be retrieved from the ContentAddressableStorage.
				322	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				323	"sizeBytes": "A String", # The size of the blob, in bytes.
				324	},
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	325	"executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	326	"inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.
				327	"inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	328	"workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	329	"outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.
				330	"executionCompletedTimestamp": "A String", # When the worker completed executing the action command.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	331	"workerStartTimestamp": "A String", # When the worker received the action.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	332	"outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	333	"queuedTimestamp": "A String", # When was the action added to the queue.
				334	"worker": "A String", # The name of the worker which ran the execution.
				335	"executionStartTimestamp": "A String", # When the worker started executing the action command.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	336	},
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	337	"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.
				338	{ # An `OutputSymlink` is similar to a Symlink, but it is used as an output in an `ActionResult`. `OutputSymlink` is binary-compatible with `SymlinkNode`.
				339	"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.
				340	"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the Action.
				341	{ # 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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	342	"value": "A String", # The property value.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	343	"name": "A String", # The property name.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	344	},
				345	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	346	"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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	347	},
				348	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	349	"stdoutDigest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest for a blob containing the standard output of the action, which can be retrieved from the ContentAddressableStorage.
				350	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				351	"sizeBytes": "A String", # The size of the blob, in bytes.
				352	},
				353	"exitCode": 42, # The exit code of the command.
				354	"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.
				355	"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.
				356	{ # 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.
				357	"isExecutable": True or False, # True if file is executable, false otherwise.
				358	"nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.
				359	{ # 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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	360	"value": "A String", # The property value.
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	361	"name": "A String", # The property name.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	362	},
				363	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	364	"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.
				365	"digest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest of the file's content.
				366	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				367	"sizeBytes": "A String", # The size of the blob, in bytes.
				368	},
				369	"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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	370	},
				371	],
Dmitry Frenkel	3e17f89	2020-10-06 16:46:05 -0700	[diff] [blame^]	372	"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.
				373	{ # An `OutputDirectory` is the output in an `ActionResult` corresponding to a directory's full contents rather than a single file.
				374	"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.
				375	"treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob and its hash. The hash algorithm to use is defined by the server. 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. # The digest of the encoded Tree proto containing the directory's contents.
				376	"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string exactly 64 characters long.
				377	"sizeBytes": "A String", # The size of the blob, in bytes.
				378	},
				379	},
				380	],
				381	"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`.
				382	{ # An `OutputSymlink` is similar to a Symlink, but it is used as an output in an `ActionResult`. `OutputSymlink` is binary-compatible with `SymlinkNode`.
				383	"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.
				384	"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the Action.
				385	{ # 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.
				386	"value": "A String", # The property value.
				387	"name": "A String", # The property name.
				388	},
				389	],
				390	"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.
				391	},
				392	],
				393	"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.
Bu Sun Kim	d059ad8	2020-07-22 17:02:09 -0700	[diff] [blame]	394	}</pre>
Bu Sun Kim	715bd7f	2019-06-14 16:50:42 -0700	[diff] [blame]	395	</div>
				396
				397	</body></html>