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

2020-07-22 17:02:09 -0700

[diff] [blame^]

78

<code><a href="#get">get(instanceName, hash, sizeBytes, inlineStderr=None, inlineStdout=None, inlineOutputFiles=None, x__xgafv=None)</a></code></p>

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

79

<p class="firstline">Retrieve a cached execution result.</p>

80

Dan O'Meara

dd49464

2020-05-01 07:42:23 -0700

[diff] [blame]

81

<code><a href="#update">update(instanceName, hash, sizeBytes, body=None, resultsCachePolicy_priority=None, x__xgafv=None)</a></code></p>

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

82

<p class="firstline">Upload a new execution result.</p>

83

<h3>Method Details</h3>

84

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

85

<code class="details" id="get">get(instanceName, hash, sizeBytes, inlineStderr=None, inlineStdout=None, inlineOutputFiles=None, x__xgafv=None)</code>

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

86

<pre>Retrieve a cached execution result.

87

88

Implementations SHOULD ensure that any blobs referenced from the

89

ContentAddressableStorage

90

are available at the time of returning the

91

ActionResult and will be

92

for some period of time afterwards. The TTLs of the referenced blobs SHOULD be increased

93

if necessary and applicable.

Errors:

* `NOT_FOUND`: The requested `ActionResult` is not in the cache.

98

99

Args:

100

instanceName: string, The instance of the execution system to operate against. A server may

101

support multiple instances of the execution system (with their own workers,

102

storage, caches, etc.). The server MAY require use of this field to select

103

between them in an implementation-defined fashion, otherwise it can be

104

omitted. (required)

105

hash: string, The hash. In the case of SHA-256, it will always be a lowercase hex string

106

exactly 64 characters long. (required)

107

sizeBytes: string, The size of the blob, in bytes. (required)

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

108

inlineStderr: boolean, A hint to the server to request inlining stderr in the

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

109

ActionResult message.

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

110

inlineStdout: boolean, A hint to the server to request inlining stdout in the

111

ActionResult message.

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

112

inlineOutputFiles: string, A hint to the server to inline the contents of the listed output files.

113

Each path needs to exactly match one path in `output_files` in the

114

Command message. (repeated)

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

115

x__xgafv: string, V1 error format.

Allowed values

1 - v1 error format

2 - v2 error format

Returns:

An object of the form:

122

123

{ # An ActionResult represents the result of an

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

124

# Action being run.

125

"outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. Those

126

# may be links to other output files, or input files, or even absolute paths

127

# outside of the working directory, if the server supports

128

# SymlinkAbsolutePathStrategy.ALLOWED.

129

# For each output file requested in the `output_files` or `output_paths`

130

# field of the Action, if the corresponding file existed after

131

# the action completed, a single entry will be present either in this field,

132

# or in the `output_files` field, if the file was not a symbolic link.

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

133

#

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

134

# If an output symbolic link of the same name as listed in `output_files` of

135

# the Command was found, but its target type was not a regular file, the

136

# server will return a FAILED_PRECONDITION.

137

# If the action does not produce the requested output, then that output

138

# will be omitted from the list. The server is free to arrange the output

139

# list as desired; clients MUST NOT assume that the output list is sorted.

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

140

#

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

141

# DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API

142

# should still populate this field in addition to `output_symlinks`.

143

{ # An `OutputSymlink` is similar to a

144

# Symlink, but it is used as an

145

# output in an `ActionResult`.

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

146

#

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

147

# `OutputSymlink` is binary-compatible with `SymlinkNode`.

148

"path": "A String", # The full path of the symlink relative to the working directory, including the

149

# filename. The path separator is a forward slash `/`. Since this is a

150

# relative path, it MUST NOT begin with a leading forward slash.

151

"target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.

152

# The target path can be relative to the parent directory of the symlink or

153

# it can be an absolute path starting with `/`. Support for absolute paths

154

# can be checked using the Capabilities

155

# API. The canonical form forbids the substrings `/./` and `//` in the target

156

# path. `..` components are allowed anywhere in the target path.

157

"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the

158

# Action.

159

{ # A single property for FileNodes,

160

# DirectoryNodes, and

161

# SymlinkNodes. The server is

162

# responsible for specifying the property `name`s that it accepts. If

163

# permitted by the server, the same `name` may occur multiple times.

164

"name": "A String", # The property name.

165

"value": "A String", # The property value.

166

},

167

],

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

168

},

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

169

],

170

"exitCode": 42, # The exit code of the command.

171

"stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline

172

# stdout unless requested by the client in the

173

# GetActionResultRequest

174

# message. The server MAY omit inlining, even if requested, and MUST do so if inlining

175

# would cause the response to exceed message size limits.

176

"outputFiles": [ # The output files of the action. For each output file requested in the

177

# `output_files` or `output_paths` field of the Action, if the corresponding

178

# file existed after the action completed, a single entry will be present

179

# either in this field, or the `output_file_symlinks` field if the file was

180

# a symbolic link to another file (`output_symlinks` field after v2.1).

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

181

#

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

182

# If an output listed in `output_files` was found, but was a directory rather

183

# than a regular file, the server will return a FAILED_PRECONDITION.

184

# If the action does not produce the requested output, then that output

185

# will be omitted from the list. The server is free to arrange the output

186

# list as desired; clients MUST NOT assume that the output list is sorted.

187

{ # An `OutputFile` is similar to a

188

# FileNode, but it is used as an

189

# output in an `ActionResult`. It allows a full file path rather than

190

# only a name.

191

"isExecutable": True or False, # True if file is executable, false otherwise.

192

"digest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the file's content.

193

# and its hash. The hash algorithm to use is defined by the server.

194

#

195

# The size is considered to be an integral part of the digest and cannot be

196

# separated. That is, even if the `hash` field is correctly specified but

197

# `size_bytes` is not, the server MUST reject the request.

198

#

199

# The reason for including the size in the digest is as follows: in a great

200

# many cases, the server needs to know the size of the blob it is about to work

201

# with prior to starting an operation with it, such as flattening Merkle tree

202

# structures or streaming it to a worker. Technically, the server could

203

# implement a separate metadata store, but this results in a significantly more

204

# complicated implementation as opposed to having the client specify the size

205

# up-front (or storing the size along with the digest in every message where

206

# digests are embedded). This does mean that the API leaks some implementation

207

# details of (what we consider to be) a reasonable server implementation, but

208

# we consider this to be a worthwhile tradeoff.

209

#

210

# When a `Digest` is used to refer to a proto message, it always refers to the

211

# message in binary encoded form. To ensure consistent hashing, clients and

212

# servers MUST ensure that they serialize messages according to the following

213

# rules, even if there are alternate valid encodings for the same message:

214

#

215

# * Fields are serialized in tag order.

216

# * There are no unknown fields.

217

# * There are no duplicate fields.

218

# * Fields are serialized according to the default semantics for their type.

219

#

220

# Most protocol buffer implementations will always follow these rules when

221

# serializing, but care should be taken to avoid shortcuts. For instance,

222

# concatenating two messages to merge them may produce duplicate fields.

223

"sizeBytes": "A String", # The size of the blob, in bytes.

224

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

225

# exactly 64 characters long.

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

226

},

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

227

"contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NOT inline

228

# file contents unless requested by the client in the

229

# GetActionResultRequest

230

# message. The server MAY omit inlining, even if requested, and MUST do so if inlining

231

# would cause the response to exceed message size limits.

232

"path": "A String", # The full path of the file relative to the working directory, including the

233

# filename. The path separator is a forward slash `/`. Since this is a

234

# relative path, it MUST NOT begin with a leading forward slash.

235

"nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.

236

{ # A single property for FileNodes,

237

# DirectoryNodes, and

238

# SymlinkNodes. The server is

239

# responsible for specifying the property `name`s that it accepts. If

240

# permitted by the server, the same `name` may occur multiple times.

241

"name": "A String", # The property name.

242

"value": "A String", # The property value.

243

},

244

],

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

245

},

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

246

],

247

"outputDirectories": [ # The output directories of the action. For each output directory requested

248

# in the `output_directories` or `output_paths` field of the Action, if the

249

# corresponding directory existed after the action completed, a single entry

250

# will be present in the output list, which will contain the digest of a

251

# Tree message containing the

252

# directory tree, and the path equal exactly to the corresponding Action

253

# output_directories member.

254

#

255

# As an example, suppose the Action had an output directory `a/b/dir` and the

256

# execution produced the following contents in `a/b/dir`: a file named `bar`

257

# and a directory named `foo` with an executable file named `baz`. Then,

258

# output_directory will contain (hashes shortened for readability):

259

#

260

# ```json

261

# // 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...",

298

# size: 1294,

299

# },

300

# is_executable: true

# }

# ]

# }

# }

# ```

# If an output of the same name as listed in `output_files` of

307

# the Command was found in `output_directories`, but was not a directory, the

308

# server will return a FAILED_PRECONDITION.

309

{ # An `OutputDirectory` is the output in an `ActionResult` corresponding to a

310

# directory's full contents rather than a single file.

311

"path": "A String", # The full path of the directory relative to the working directory. The path

312

# separator is a forward slash `/`. Since this is a relative path, it MUST

313

# NOT begin with a leading forward slash. The empty string value is allowed,

314

# and it denotes the entire working directory.

315

"treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the encoded

316

# Tree proto containing the

317

# directory's contents.

318

# and its hash. The hash algorithm to use is defined by the server.

319

#

320

# The size is considered to be an integral part of the digest and cannot be

321

# separated. That is, even if the `hash` field is correctly specified but

322

# `size_bytes` is not, the server MUST reject the request.

323

#

324

# The reason for including the size in the digest is as follows: in a great

325

# many cases, the server needs to know the size of the blob it is about to work

326

# with prior to starting an operation with it, such as flattening Merkle tree

327

# structures or streaming it to a worker. Technically, the server could

328

# implement a separate metadata store, but this results in a significantly more

329

# complicated implementation as opposed to having the client specify the size

330

# up-front (or storing the size along with the digest in every message where

331

# digests are embedded). This does mean that the API leaks some implementation

332

# details of (what we consider to be) a reasonable server implementation, but

333

# we consider this to be a worthwhile tradeoff.

334

#

335

# When a `Digest` is used to refer to a proto message, it always refers to the

336

# message in binary encoded form. To ensure consistent hashing, clients and

337

# servers MUST ensure that they serialize messages according to the following

338

# rules, even if there are alternate valid encodings for the same message:

339

#

340

# * Fields are serialized in tag order.

341

# * There are no unknown fields.

342

# * There are no duplicate fields.

343

# * Fields are serialized according to the default semantics for their type.

344

#

345

# Most protocol buffer implementations will always follow these rules when

346

# serializing, but care should be taken to avoid shortcuts. For instance,

347

# concatenating two messages to merge them may produce duplicate fields.

348

"sizeBytes": "A String", # The size of the blob, in bytes.

349

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

350

# exactly 64 characters long.

Bu Sun Kim

4ed7d3f

2020-05-27 12:20:54 -0700

[diff] [blame]

351

},

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

352

},

353

],

354

"stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline

355

# stderr unless requested by the client in the

356

# GetActionResultRequest

357

# message. The server MAY omit inlining, even if requested, and MUST do so if inlining

358

# would cause the response to exceed message size limits.

359

"executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.

360

"workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.

361

"executionStartTimestamp": "A String", # When the worker started executing the action command.

362

"outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.

363

"executionCompletedTimestamp": "A String", # When the worker completed executing the action command.

364

"inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.

365

"worker": "A String", # The name of the worker which ran the execution.

366

"queuedTimestamp": "A String", # When was the action added to the queue.

367

"workerStartTimestamp": "A String", # When the worker received the action.

368

"inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.

369

"outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

370

},

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

371

"outputSymlinks": [ # New in v2.1: this field will only be populated if the command

372

# `output_paths` field was used, and not the pre v2.1 `output_files` or

373

# `output_directories` fields.

374

# The output paths of the action that are symbolic links to other paths. Those

375

# may be links to other outputs, or inputs, or even absolute paths

376

# outside of the working directory, if the server supports

377

# SymlinkAbsolutePathStrategy.ALLOWED.

378

# A single entry for each output requested in `output_paths`

379

# field of the Action, if the corresponding path existed after

380

# the action completed and was a symbolic link.

381

#

382

# If the action does not produce a requested output, then that output

383

# will be omitted from the list. The server is free to arrange the output

384

# list as desired; clients MUST NOT assume that the output list is sorted.

385

{ # An `OutputSymlink` is similar to a

386

# Symlink, but it is used as an

387

# output in an `ActionResult`.

388

#

389

# `OutputSymlink` is binary-compatible with `SymlinkNode`.

390

"path": "A String", # The full path of the symlink relative to the working directory, including the

391

# filename. The path separator is a forward slash `/`. Since this is a

392

# relative path, it MUST NOT begin with a leading forward slash.

393

"target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.

394

# The target path can be relative to the parent directory of the symlink or

395

# it can be an absolute path starting with `/`. Support for absolute paths

396

# can be checked using the Capabilities

397

# API. The canonical form forbids the substrings `/./` and `//` in the target

398

# path. `..` components are allowed anywhere in the target path.

399

"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the

400

# Action.

401

{ # A single property for FileNodes,

402

# DirectoryNodes, and

403

# SymlinkNodes. The server is

404

# responsible for specifying the property `name`s that it accepts. If

405

# permitted by the server, the same `name` may occur multiple times.

406

"name": "A String", # The property name.

407

"value": "A String", # The property value.

},

],

},

],

"outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to other

413

# directories. Those may be links to other output directories, or input

414

# directories, or even absolute paths outside of the working directory,

415

# if the server supports

416

# SymlinkAbsolutePathStrategy.ALLOWED.

417

# For each output directory requested in the `output_directories` field of

418

# the Action, if the directory existed after the action completed, a

419

# single entry will be present either in this field, or in the

420

# `output_directories` field, if the directory was not a symbolic link.

421

#

422

# If an output of the same name was found, but was a symbolic link to a file

423

# instead of a directory, the server will return a FAILED_PRECONDITION.

424

# If the action does not produce the requested output, then that output

425

# will be omitted from the list. The server is free to arrange the output

426

# list as desired; clients MUST NOT assume that the output list is sorted.

427

#

428

# DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API

429

# should still populate this field in addition to `output_symlinks`.

430

{ # An `OutputSymlink` is similar to a

431

# Symlink, but it is used as an

432

# output in an `ActionResult`.

433

#

434

# `OutputSymlink` is binary-compatible with `SymlinkNode`.

435

"path": "A String", # The full path of the symlink relative to the working directory, including the

436

# filename. The path separator is a forward slash `/`. Since this is a

437

# relative path, it MUST NOT begin with a leading forward slash.

438

"target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.

439

# The target path can be relative to the parent directory of the symlink or

440

# it can be an absolute path starting with `/`. Support for absolute paths

441

# can be checked using the Capabilities

442

# API. The canonical form forbids the substrings `/./` and `//` in the target

443

# path. `..` components are allowed anywhere in the target path.

444

"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the

445

# Action.

446

{ # A single property for FileNodes,

447

# DirectoryNodes, and

448

# SymlinkNodes. The server is

449

# responsible for specifying the property `name`s that it accepts. If

450

# permitted by the server, the same `name` may occur multiple times.

451

"name": "A String", # The property name.

452

"value": "A String", # The property value.

},

],

},

],

"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

458

# can be retrieved from the

459

# ContentAddressableStorage.

460

# and its hash. The hash algorithm to use is defined by the server.

461

#

462

# The size is considered to be an integral part of the digest and cannot be

463

# separated. That is, even if the `hash` field is correctly specified but

464

# `size_bytes` is not, the server MUST reject the request.

465

#

466

# The reason for including the size in the digest is as follows: in a great

467

# many cases, the server needs to know the size of the blob it is about to work

468

# with prior to starting an operation with it, such as flattening Merkle tree

469

# structures or streaming it to a worker. Technically, the server could

470

# implement a separate metadata store, but this results in a significantly more

471

# complicated implementation as opposed to having the client specify the size

472

# up-front (or storing the size along with the digest in every message where

473

# digests are embedded). This does mean that the API leaks some implementation

474

# details of (what we consider to be) a reasonable server implementation, but

475

# we consider this to be a worthwhile tradeoff.

476

#

477

# When a `Digest` is used to refer to a proto message, it always refers to the

478

# message in binary encoded form. To ensure consistent hashing, clients and

479

# servers MUST ensure that they serialize messages according to the following

480

# rules, even if there are alternate valid encodings for the same message:

481

#

482

# * Fields are serialized in tag order.

483

# * There are no unknown fields.

484

# * There are no duplicate fields.

485

# * Fields are serialized according to the default semantics for their type.

486

#

487

# Most protocol buffer implementations will always follow these rules when

488

# serializing, but care should be taken to avoid shortcuts. For instance,

489

# concatenating two messages to merge them may produce duplicate fields.

490

"sizeBytes": "A String", # The size of the blob, in bytes.

491

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

492

# exactly 64 characters long.

493

},

494

"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

495

# can be retrieved from the

496

# ContentAddressableStorage.

497

# and its hash. The hash algorithm to use is defined by the server.

498

#

499

# The size is considered to be an integral part of the digest and cannot be

500

# separated. That is, even if the `hash` field is correctly specified but

501

# `size_bytes` is not, the server MUST reject the request.

502

#

503

# The reason for including the size in the digest is as follows: in a great

504

# many cases, the server needs to know the size of the blob it is about to work

505

# with prior to starting an operation with it, such as flattening Merkle tree

506

# structures or streaming it to a worker. Technically, the server could

507

# implement a separate metadata store, but this results in a significantly more

508

# complicated implementation as opposed to having the client specify the size

509

# up-front (or storing the size along with the digest in every message where

510

# digests are embedded). This does mean that the API leaks some implementation

511

# details of (what we consider to be) a reasonable server implementation, but

512

# we consider this to be a worthwhile tradeoff.

513

#

514

# When a `Digest` is used to refer to a proto message, it always refers to the

515

# message in binary encoded form. To ensure consistent hashing, clients and

516

# servers MUST ensure that they serialize messages according to the following

517

# rules, even if there are alternate valid encodings for the same message:

518

#

519

# * Fields are serialized in tag order.

520

# * There are no unknown fields.

521

# * There are no duplicate fields.

522

# * Fields are serialized according to the default semantics for their type.

523

#

524

# Most protocol buffer implementations will always follow these rules when

525

# serializing, but care should be taken to avoid shortcuts. For instance,

526

# concatenating two messages to merge them may produce duplicate fields.

527

"sizeBytes": "A String", # The size of the blob, in bytes.

528

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

529

# exactly 64 characters long.

530

},

531

}</pre>

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

</div>

Dan O'Meara

2020-05-01 07:42:23 -0700

[diff] [blame]

535

<code class="details" id="update">update(instanceName, hash, sizeBytes, body=None, resultsCachePolicy_priority=None, x__xgafv=None)</code>

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

536

<pre>Upload a new execution result.

537

538

In order to allow the server to perform access control based on the type of

539

action, and to assist with client debugging, the client MUST first upload

540

the Action that produced the

541

result, along with its

542

Command, into the

543

`ContentAddressableStorage`.

Errors:

* `INVALID_ARGUMENT`: One or more arguments are invalid.

548

* `FAILED_PRECONDITION`: One or more errors occurred in updating the

549

action result, such as a missing command or action.

550

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

555

support multiple instances of the execution system (with their own workers,

556

storage, caches, etc.). The server MAY require use of this field to select

557

between them in an implementation-defined fashion, otherwise it can be

558

omitted. (required)

559

hash: string, The hash. In the case of SHA-256, it will always be a lowercase hex string

560

exactly 64 characters long. (required)

561

sizeBytes: string, The size of the blob, in bytes. (required)

Dan O'Meara

dd49464

2020-05-01 07:42:23 -0700

[diff] [blame]

562

body: object, The request body.

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

563

The object takes the form of:

564

565

{ # An ActionResult represents the result of an

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

566

# Action being run.

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

567

"outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. Those

568

# may be links to other output files, or input files, or even absolute paths

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

569

# outside of the working directory, if the server supports

570

# SymlinkAbsolutePathStrategy.ALLOWED.

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

571

# For each output file requested in the `output_files` or `output_paths`

572

# field of the Action, if the corresponding file existed after

573

# the action completed, a single entry will be present either in this field,

574

# or in the `output_files` field, if the file was not a symbolic link.

575

#

576

# If an output symbolic link of the same name as listed in `output_files` of

577

# the Command was found, but its target type was not a regular file, the

578

# server will return a FAILED_PRECONDITION.

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

579

# If the action does not produce the requested output, then that output

580

# will be omitted from the list. The server is free to arrange the output

581

# list as desired; clients MUST NOT assume that the output list is sorted.

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

582

#

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

583

# DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API

584

# should still populate this field in addition to `output_symlinks`.

585

{ # An `OutputSymlink` is similar to a

586

# Symlink, but it is used as an

587

# output in an `ActionResult`.

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

588

#

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

589

# `OutputSymlink` is binary-compatible with `SymlinkNode`.

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

590

"path": "A String", # The full path of the symlink relative to the working directory, including the

591

# filename. The path separator is a forward slash `/`. Since this is a

592

# relative path, it MUST NOT begin with a leading forward slash.

593

"target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.

594

# The target path can be relative to the parent directory of the symlink or

595

# it can be an absolute path starting with `/`. Support for absolute paths

596

# can be checked using the Capabilities

597

# API. The canonical form forbids the substrings `/./` and `//` in the target

598

# path. `..` components are allowed anywhere in the target path.

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

599

"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the

600

# Action.

601

{ # A single property for FileNodes,

602

# DirectoryNodes, and

603

# SymlinkNodes. The server is

604

# responsible for specifying the property `name`s that it accepts. If

605

# permitted by the server, the same `name` may occur multiple times.

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

606

"name": "A String", # The property name.

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

607

"value": "A String", # The property value.

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

608

},

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

609

],

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

610

},

611

],

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

612

"exitCode": 42, # The exit code of the command.

613

"stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline

614

# stdout unless requested by the client in the

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

615

# GetActionResultRequest

616

# message. The server MAY omit inlining, even if requested, and MUST do so if inlining

617

# would cause the response to exceed message size limits.

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

618

"outputFiles": [ # The output files of the action. For each output file requested in the

619

# `output_files` or `output_paths` field of the Action, if the corresponding

620

# file existed after the action completed, a single entry will be present

621

# either in this field, or the `output_file_symlinks` field if the file was

622

# a symbolic link to another file (`output_symlinks` field after v2.1).

623

#

624

# If an output listed in `output_files` was found, but was a directory rather

625

# than a regular file, the server will return a FAILED_PRECONDITION.

626

# If the action does not produce the requested output, then that output

627

# will be omitted from the list. The server is free to arrange the output

628

# list as desired; clients MUST NOT assume that the output list is sorted.

629

{ # An `OutputFile` is similar to a

630

# FileNode, but it is used as an

631

# output in an `ActionResult`. It allows a full file path rather than

632

# only a name.

633

"isExecutable": True or False, # True if file is executable, false otherwise.

634

"digest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the file's content.

635

# and its hash. The hash algorithm to use is defined by the server.

636

#

637

# The size is considered to be an integral part of the digest and cannot be

638

# separated. That is, even if the `hash` field is correctly specified but

639

# `size_bytes` is not, the server MUST reject the request.

640

#

641

# The reason for including the size in the digest is as follows: in a great

642

# many cases, the server needs to know the size of the blob it is about to work

643

# with prior to starting an operation with it, such as flattening Merkle tree

644

# structures or streaming it to a worker. Technically, the server could

645

# implement a separate metadata store, but this results in a significantly more

646

# complicated implementation as opposed to having the client specify the size

647

# up-front (or storing the size along with the digest in every message where

648

# digests are embedded). This does mean that the API leaks some implementation

649

# details of (what we consider to be) a reasonable server implementation, but

650

# we consider this to be a worthwhile tradeoff.

651

#

652

# When a `Digest` is used to refer to a proto message, it always refers to the

653

# message in binary encoded form. To ensure consistent hashing, clients and

654

# servers MUST ensure that they serialize messages according to the following

655

# rules, even if there are alternate valid encodings for the same message:

656

#

657

# * Fields are serialized in tag order.

658

# * There are no unknown fields.

659

# * There are no duplicate fields.

660

# * Fields are serialized according to the default semantics for their type.

661

#

662

# Most protocol buffer implementations will always follow these rules when

663

# serializing, but care should be taken to avoid shortcuts. For instance,

664

# concatenating two messages to merge them may produce duplicate fields.

665

"sizeBytes": "A String", # The size of the blob, in bytes.

666

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

667

# exactly 64 characters long.

668

},

669

"contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NOT inline

670

# file contents unless requested by the client in the

671

# GetActionResultRequest

672

# message. The server MAY omit inlining, even if requested, and MUST do so if inlining

673

# would cause the response to exceed message size limits.

674

"path": "A String", # The full path of the file relative to the working directory, including the

675

# filename. The path separator is a forward slash `/`. Since this is a

676

# relative path, it MUST NOT begin with a leading forward slash.

677

"nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.

678

{ # A single property for FileNodes,

679

# DirectoryNodes, and

680

# SymlinkNodes. The server is

681

# responsible for specifying the property `name`s that it accepts. If

682

# permitted by the server, the same `name` may occur multiple times.

683

"name": "A String", # The property name.

684

"value": "A String", # The property value.

},

],

},

],

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

689

"outputDirectories": [ # The output directories of the action. For each output directory requested

690

# in the `output_directories` or `output_paths` field of the Action, if the

691

# corresponding directory existed after the action completed, a single entry

692

# will be present in the output list, which will contain the digest of a

693

# Tree message containing the

694

# directory tree, and the path equal exactly to the corresponding Action

695

# output_directories member.

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

696

#

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

697

# As an example, suppose the Action had an output directory `a/b/dir` and the

698

# execution produced the following contents in `a/b/dir`: a file named `bar`

699

# and a directory named `foo` with an executable file named `baz`. Then,

700

# output_directory will contain (hashes shortened for readability):

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

701

#

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

702

# ```json

703

# // 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...",

740

# size: 1294,

741

# },

742

# is_executable: true

# }

# ]

# }

# }

# ```

# If an output of the same name as listed in `output_files` of

749

# the Command was found in `output_directories`, but was not a directory, the

750

# server will return a FAILED_PRECONDITION.

751

{ # An `OutputDirectory` is the output in an `ActionResult` corresponding to a

752

# directory's full contents rather than a single file.

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

753

"path": "A String", # The full path of the directory relative to the working directory. The path

754

# separator is a forward slash `/`. Since this is a relative path, it MUST

755

# NOT begin with a leading forward slash. The empty string value is allowed,

756

# and it denotes the entire working directory.

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

757

"treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the encoded

758

# Tree proto containing the

759

# directory's contents.

760

# and its hash. The hash algorithm to use is defined by the server.

761

#

762

# The size is considered to be an integral part of the digest and cannot be

763

# separated. That is, even if the `hash` field is correctly specified but

764

# `size_bytes` is not, the server MUST reject the request.

765

#

766

# The reason for including the size in the digest is as follows: in a great

767

# many cases, the server needs to know the size of the blob it is about to work

768

# with prior to starting an operation with it, such as flattening Merkle tree

769

# structures or streaming it to a worker. Technically, the server could

770

# implement a separate metadata store, but this results in a significantly more

771

# complicated implementation as opposed to having the client specify the size

772

# up-front (or storing the size along with the digest in every message where

773

# digests are embedded). This does mean that the API leaks some implementation

774

# details of (what we consider to be) a reasonable server implementation, but

775

# we consider this to be a worthwhile tradeoff.

776

#

777

# When a `Digest` is used to refer to a proto message, it always refers to the

778

# message in binary encoded form. To ensure consistent hashing, clients and

779

# servers MUST ensure that they serialize messages according to the following

780

# rules, even if there are alternate valid encodings for the same message:

781

#

782

# * Fields are serialized in tag order.

783

# * There are no unknown fields.

784

# * There are no duplicate fields.

785

# * Fields are serialized according to the default semantics for their type.

786

#

787

# Most protocol buffer implementations will always follow these rules when

788

# serializing, but care should be taken to avoid shortcuts. For instance,

789

# concatenating two messages to merge them may produce duplicate fields.

790

"sizeBytes": "A String", # The size of the blob, in bytes.

791

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

792

# exactly 64 characters long.

Bu Sun Kim

2019-06-14 16:50:42 -0700

[diff] [blame]

793

},

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

794

},

795

],

796

"stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline

797

# stderr unless requested by the client in the

798

# GetActionResultRequest

799

# message. The server MAY omit inlining, even if requested, and MUST do so if inlining

800

# would cause the response to exceed message size limits.

801

"executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.

802

"workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.

803

"executionStartTimestamp": "A String", # When the worker started executing the action command.

804

"outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.

805

"executionCompletedTimestamp": "A String", # When the worker completed executing the action command.

806

"inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.

807

"worker": "A String", # The name of the worker which ran the execution.

808

"queuedTimestamp": "A String", # When was the action added to the queue.

809

"workerStartTimestamp": "A String", # When the worker received the action.

810

"inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.

811

"outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.

812

},

813

"outputSymlinks": [ # New in v2.1: this field will only be populated if the command

814

# `output_paths` field was used, and not the pre v2.1 `output_files` or

815

# `output_directories` fields.

816

# The output paths of the action that are symbolic links to other paths. Those

817

# may be links to other outputs, or inputs, or even absolute paths

818

# outside of the working directory, if the server supports

819

# SymlinkAbsolutePathStrategy.ALLOWED.

820

# A single entry for each output requested in `output_paths`

821

# field of the Action, if the corresponding path existed after

822

# the action completed and was a symbolic link.

823

#

824

# If the action does not produce a requested output, then that output

825

# will be omitted from the list. The server is free to arrange the output

826

# list as desired; clients MUST NOT assume that the output list is sorted.

827

{ # An `OutputSymlink` is similar to a

828

# Symlink, but it is used as an

829

# output in an `ActionResult`.

830

#

831

# `OutputSymlink` is binary-compatible with `SymlinkNode`.

832

"path": "A String", # The full path of the symlink relative to the working directory, including the

833

# filename. The path separator is a forward slash `/`. Since this is a

834

# relative path, it MUST NOT begin with a leading forward slash.

835

"target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.

836

# The target path can be relative to the parent directory of the symlink or

837

# it can be an absolute path starting with `/`. Support for absolute paths

838

# can be checked using the Capabilities

839

# API. The canonical form forbids the substrings `/./` and `//` in the target

840

# path. `..` components are allowed anywhere in the target path.

841

"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the

842

# Action.

843

{ # A single property for FileNodes,

844

# DirectoryNodes, and

845

# SymlinkNodes. The server is

846

# responsible for specifying the property `name`s that it accepts. If

847

# permitted by the server, the same `name` may occur multiple times.

848

"name": "A String", # The property name.

849

"value": "A String", # The property value.

},

],

},

],

"outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to other

855

# directories. Those may be links to other output directories, or input

856

# directories, or even absolute paths outside of the working directory,

857

# if the server supports

858

# SymlinkAbsolutePathStrategy.ALLOWED.

859

# For each output directory requested in the `output_directories` field of

860

# the Action, if the directory existed after the action completed, a

861

# single entry will be present either in this field, or in the

862

# `output_directories` field, if the directory was not a symbolic link.

863

#

864

# If an output of the same name was found, but was a symbolic link to a file

865

# instead of a directory, the server will return a FAILED_PRECONDITION.

866

# If the action does not produce the requested output, then that output

867

# will be omitted from the list. The server is free to arrange the output

868

# list as desired; clients MUST NOT assume that the output list is sorted.

869

#

870

# DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API

871

# should still populate this field in addition to `output_symlinks`.

872

{ # An `OutputSymlink` is similar to a

873

# Symlink, but it is used as an

874

# output in an `ActionResult`.

875

#

876

# `OutputSymlink` is binary-compatible with `SymlinkNode`.

877

"path": "A String", # The full path of the symlink relative to the working directory, including the

878

# filename. The path separator is a forward slash `/`. Since this is a

879

# relative path, it MUST NOT begin with a leading forward slash.

880

"target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.

881

# The target path can be relative to the parent directory of the symlink or

882

# it can be an absolute path starting with `/`. Support for absolute paths

883

# can be checked using the Capabilities

884

# API. The canonical form forbids the substrings `/./` and `//` in the target

885

# path. `..` components are allowed anywhere in the target path.

886

"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the

887

# Action.

888

{ # A single property for FileNodes,

889

# DirectoryNodes, and

890

# SymlinkNodes. The server is

891

# responsible for specifying the property `name`s that it accepts. If

892

# permitted by the server, the same `name` may occur multiple times.

893

"name": "A String", # The property name.

894

"value": "A String", # The property value.

895

},

896

],

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

897

},

898

],

899

"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

900

# can be retrieved from the

901

# ContentAddressableStorage.

902

# and its hash. The hash algorithm to use is defined by the server.

903

#

904

# The size is considered to be an integral part of the digest and cannot be

905

# separated. That is, even if the `hash` field is correctly specified but

906

# `size_bytes` is not, the server MUST reject the request.

907

#

908

# The reason for including the size in the digest is as follows: in a great

909

# many cases, the server needs to know the size of the blob it is about to work

910

# with prior to starting an operation with it, such as flattening Merkle tree

911

# structures or streaming it to a worker. Technically, the server could

912

# implement a separate metadata store, but this results in a significantly more

913

# complicated implementation as opposed to having the client specify the size

914

# up-front (or storing the size along with the digest in every message where

915

# digests are embedded). This does mean that the API leaks some implementation

916

# details of (what we consider to be) a reasonable server implementation, but

917

# we consider this to be a worthwhile tradeoff.

918

#

919

# When a `Digest` is used to refer to a proto message, it always refers to the

920

# message in binary encoded form. To ensure consistent hashing, clients and

921

# servers MUST ensure that they serialize messages according to the following

922

# rules, even if there are alternate valid encodings for the same message:

923

#

924

# * Fields are serialized in tag order.

925

# * There are no unknown fields.

926

# * There are no duplicate fields.

927

# * Fields are serialized according to the default semantics for their type.

928

#

929

# Most protocol buffer implementations will always follow these rules when

930

# serializing, but care should be taken to avoid shortcuts. For instance,

931

# concatenating two messages to merge them may produce duplicate fields.

932

"sizeBytes": "A String", # The size of the blob, in bytes.

933

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

934

# exactly 64 characters long.

935

},

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

936

"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

937

# can be retrieved from the

938

# ContentAddressableStorage.

939

# and its hash. The hash algorithm to use is defined by the server.

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

940

#

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

941

# The size is considered to be an integral part of the digest and cannot be

942

# separated. That is, even if the `hash` field is correctly specified but

943

# `size_bytes` is not, the server MUST reject the request.

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

944

#

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

945

# The reason for including the size in the digest is as follows: in a great

946

# many cases, the server needs to know the size of the blob it is about to work

947

# with prior to starting an operation with it, such as flattening Merkle tree

948

# structures or streaming it to a worker. Technically, the server could

949

# implement a separate metadata store, but this results in a significantly more

950

# complicated implementation as opposed to having the client specify the size

951

# up-front (or storing the size along with the digest in every message where

952

# digests are embedded). This does mean that the API leaks some implementation

953

# details of (what we consider to be) a reasonable server implementation, but

954

# we consider this to be a worthwhile tradeoff.

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

955

#

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

956

# When a `Digest` is used to refer to a proto message, it always refers to the

957

# message in binary encoded form. To ensure consistent hashing, clients and

958

# servers MUST ensure that they serialize messages according to the following

959

# rules, even if there are alternate valid encodings for the same message:

960

#

961

# * Fields are serialized in tag order.

962

# * There are no unknown fields.

963

# * There are no duplicate fields.

964

# * Fields are serialized according to the default semantics for their type.

965

#

966

# Most protocol buffer implementations will always follow these rules when

967

# serializing, but care should be taken to avoid shortcuts. For instance,

968

# concatenating two messages to merge them may produce duplicate fields.

969

"sizeBytes": "A String", # The size of the blob, in bytes.

970

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

971

# exactly 64 characters long.

Bu Sun Kim

2020-05-20 12:08:20 -0700

[diff] [blame]

972

},

Bu Sun Kim

2020-07-22 17:02:09 -0700

[diff] [blame^]

973

}

974

975

resultsCachePolicy_priority: integer, The priority (relative importance) of this content in the overall cache.

976

Generally, a lower value means a longer retention time or other advantage,

977

but the interpretation of a given value is server-dependent. A priority of

978

0 means a *default* value, decided by the server.

979

980

The particular semantics of this field is up to the server. In particular,

981

every server will have their own supported range of priorities, and will

982

decide how these map into retention/eviction policy.

983

x__xgafv: string, V1 error format.

Allowed values

1 - v1 error format

2 - v2 error format

Returns:

An object of the form:

990

991

{ # An ActionResult represents the result of an

992

# Action being run.

993

"outputFileSymlinks": [ # The output files of the action that are symbolic links to other files. Those

994

# may be links to other output files, or input files, or even absolute paths

995

# outside of the working directory, if the server supports

996

# SymlinkAbsolutePathStrategy.ALLOWED.

997

# For each output file requested in the `output_files` or `output_paths`

998

# field of the Action, if the corresponding file existed after

999

# the action completed, a single entry will be present either in this field,

1000

# or in the `output_files` field, if the file was not a symbolic link.

1001

#

1002

# If an output symbolic link of the same name as listed in `output_files` of

1003

# the Command was found, but its target type was not a regular file, the

1004

# server will return a FAILED_PRECONDITION.

1005

# If the action does not produce the requested output, then that output

1006

# will be omitted from the list. The server is free to arrange the output

1007

# list as desired; clients MUST NOT assume that the output list is sorted.

1008

#

1009

# DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API

1010

# should still populate this field in addition to `output_symlinks`.

1011

{ # An `OutputSymlink` is similar to a

1012

# Symlink, but it is used as an

1013

# output in an `ActionResult`.

1014

#

1015

# `OutputSymlink` is binary-compatible with `SymlinkNode`.

1016

"path": "A String", # The full path of the symlink relative to the working directory, including the

1017

# filename. The path separator is a forward slash `/`. Since this is a

1018

# relative path, it MUST NOT begin with a leading forward slash.

1019

"target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.

1020

# The target path can be relative to the parent directory of the symlink or

1021

# it can be an absolute path starting with `/`. Support for absolute paths

1022

# can be checked using the Capabilities

1023

# API. The canonical form forbids the substrings `/./` and `//` in the target

1024

# path. `..` components are allowed anywhere in the target path.

1025

"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the

1026

# Action.

1027

{ # A single property for FileNodes,

1028

# DirectoryNodes, and

1029

# SymlinkNodes. The server is

1030

# responsible for specifying the property `name`s that it accepts. If

1031

# permitted by the server, the same `name` may occur multiple times.

1032

"name": "A String", # The property name.

1033

"value": "A String", # The property value.

},

],

},

],

"exitCode": 42, # The exit code of the command.

1039

"stdoutRaw": "A String", # The standard output buffer of the action. The server SHOULD NOT inline

1040

# stdout unless requested by the client in the

1041

# GetActionResultRequest

1042

# message. The server MAY omit inlining, even if requested, and MUST do so if inlining

1043

# would cause the response to exceed message size limits.

1044

"outputFiles": [ # The output files of the action. For each output file requested in the

1045

# `output_files` or `output_paths` field of the Action, if the corresponding

1046

# file existed after the action completed, a single entry will be present

1047

# either in this field, or the `output_file_symlinks` field if the file was

1048

# a symbolic link to another file (`output_symlinks` field after v2.1).

1049

#

1050

# If an output listed in `output_files` was found, but was a directory rather

1051

# than a regular file, the server will return a FAILED_PRECONDITION.

1052

# If the action does not produce the requested output, then that output

1053

# will be omitted from the list. The server is free to arrange the output

1054

# list as desired; clients MUST NOT assume that the output list is sorted.

1055

{ # An `OutputFile` is similar to a

1056

# FileNode, but it is used as an

1057

# output in an `ActionResult`. It allows a full file path rather than

1058

# only a name.

1059

"isExecutable": True or False, # True if file is executable, false otherwise.

1060

"digest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the file's content.

1061

# and its hash. The hash algorithm to use is defined by the server.

1062

#

1063

# The size is considered to be an integral part of the digest and cannot be

1064

# separated. That is, even if the `hash` field is correctly specified but

1065

# `size_bytes` is not, the server MUST reject the request.

1066

#

1067

# The reason for including the size in the digest is as follows: in a great

1068

# many cases, the server needs to know the size of the blob it is about to work

1069

# with prior to starting an operation with it, such as flattening Merkle tree

1070

# structures or streaming it to a worker. Technically, the server could

1071

# implement a separate metadata store, but this results in a significantly more

1072

# complicated implementation as opposed to having the client specify the size

1073

# up-front (or storing the size along with the digest in every message where

1074

# digests are embedded). This does mean that the API leaks some implementation

1075

# details of (what we consider to be) a reasonable server implementation, but

1076

# we consider this to be a worthwhile tradeoff.

1077

#

1078

# When a `Digest` is used to refer to a proto message, it always refers to the

1079

# message in binary encoded form. To ensure consistent hashing, clients and

1080

# servers MUST ensure that they serialize messages according to the following

1081

# rules, even if there are alternate valid encodings for the same message:

1082

#

1083

# * Fields are serialized in tag order.

1084

# * There are no unknown fields.

1085

# * There are no duplicate fields.

1086

# * Fields are serialized according to the default semantics for their type.

1087

#

1088

# Most protocol buffer implementations will always follow these rules when

1089

# serializing, but care should be taken to avoid shortcuts. For instance,

1090

# concatenating two messages to merge them may produce duplicate fields.

1091

"sizeBytes": "A String", # The size of the blob, in bytes.

1092

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

1093

# exactly 64 characters long.

1094

},

1095

"contents": "A String", # The contents of the file if inlining was requested. The server SHOULD NOT inline

1096

# file contents unless requested by the client in the

1097

# GetActionResultRequest

1098

# message. The server MAY omit inlining, even if requested, and MUST do so if inlining

1099

# would cause the response to exceed message size limits.

1100

"path": "A String", # The full path of the file relative to the working directory, including the

1101

# filename. The path separator is a forward slash `/`. Since this is a

1102

# relative path, it MUST NOT begin with a leading forward slash.

1103

"nodeProperties": [ # The supported node properties of the OutputFile, if requested by the Action.

1104

{ # A single property for FileNodes,

1105

# DirectoryNodes, and

1106

# SymlinkNodes. The server is

1107

# responsible for specifying the property `name`s that it accepts. If

1108

# permitted by the server, the same `name` may occur multiple times.

1109

"name": "A String", # The property name.

1110

"value": "A String", # The property value.

},

],

},

],

"outputDirectories": [ # The output directories of the action. For each output directory requested

1116

# in the `output_directories` or `output_paths` field of the Action, if the

1117

# corresponding directory existed after the action completed, a single entry

1118

# will be present in the output list, which will contain the digest of a

1119

# Tree message containing the

1120

# directory tree, and the path equal exactly to the corresponding Action

1121

# output_directories member.

1122

#

1123

# As an example, suppose the Action had an output directory `a/b/dir` and the

1124

# execution produced the following contents in `a/b/dir`: a file named `bar`

1125

# and a directory named `foo` with an executable file named `baz`. Then,

1126

# output_directory will contain (hashes shortened for readability):

1127

#

1128

# ```json

1129

# // 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...",

1166

# size: 1294,

1167

# },

1168

# is_executable: true

# }

# ]

# }

# }

# ```

# If an output of the same name as listed in `output_files` of

1175

# the Command was found in `output_directories`, but was not a directory, the

1176

# server will return a FAILED_PRECONDITION.

1177

{ # An `OutputDirectory` is the output in an `ActionResult` corresponding to a

1178

# directory's full contents rather than a single file.

1179

"path": "A String", # The full path of the directory relative to the working directory. The path

1180

# separator is a forward slash `/`. Since this is a relative path, it MUST

1181

# NOT begin with a leading forward slash. The empty string value is allowed,

1182

# and it denotes the entire working directory.

1183

"treeDigest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the encoded

1184

# Tree proto containing the

1185

# directory's contents.

1186

# and its hash. The hash algorithm to use is defined by the server.

1187

#

1188

# The size is considered to be an integral part of the digest and cannot be

1189

# separated. That is, even if the `hash` field is correctly specified but

1190

# `size_bytes` is not, the server MUST reject the request.

1191

#

1192

# The reason for including the size in the digest is as follows: in a great

1193

# many cases, the server needs to know the size of the blob it is about to work

1194

# with prior to starting an operation with it, such as flattening Merkle tree

1195

# structures or streaming it to a worker. Technically, the server could

1196

# implement a separate metadata store, but this results in a significantly more

1197

# complicated implementation as opposed to having the client specify the size

1198

# up-front (or storing the size along with the digest in every message where

1199

# digests are embedded). This does mean that the API leaks some implementation

1200

# details of (what we consider to be) a reasonable server implementation, but

1201

# we consider this to be a worthwhile tradeoff.

1202

#

1203

# When a `Digest` is used to refer to a proto message, it always refers to the

1204

# message in binary encoded form. To ensure consistent hashing, clients and

1205

# servers MUST ensure that they serialize messages according to the following

1206

# rules, even if there are alternate valid encodings for the same message:

1207

#

1208

# * Fields are serialized in tag order.

1209

# * There are no unknown fields.

1210

# * There are no duplicate fields.

1211

# * Fields are serialized according to the default semantics for their type.

1212

#

1213

# Most protocol buffer implementations will always follow these rules when

1214

# serializing, but care should be taken to avoid shortcuts. For instance,

1215

# concatenating two messages to merge them may produce duplicate fields.

1216

"sizeBytes": "A String", # The size of the blob, in bytes.

1217

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

1218

# exactly 64 characters long.

},

},

],

"stderrRaw": "A String", # The standard error buffer of the action. The server SHOULD NOT inline

1223

# stderr unless requested by the client in the

1224

# GetActionResultRequest

1225

# message. The server MAY omit inlining, even if requested, and MUST do so if inlining

1226

# would cause the response to exceed message size limits.

1227

"executionMetadata": { # ExecutedActionMetadata contains details about a completed execution. # The details of the execution that originally produced this result.

1228

"workerCompletedTimestamp": "A String", # When the worker completed the action, including all stages.

1229

"executionStartTimestamp": "A String", # When the worker started executing the action command.

1230

"outputUploadStartTimestamp": "A String", # When the worker started uploading action outputs.

1231

"executionCompletedTimestamp": "A String", # When the worker completed executing the action command.

1232

"inputFetchCompletedTimestamp": "A String", # When the worker finished fetching action inputs.

1233

"worker": "A String", # The name of the worker which ran the execution.

1234

"queuedTimestamp": "A String", # When was the action added to the queue.

1235

"workerStartTimestamp": "A String", # When the worker received the action.

1236

"inputFetchStartTimestamp": "A String", # When the worker started fetching action inputs.

1237

"outputUploadCompletedTimestamp": "A String", # When the worker finished uploading action outputs.

1238

},

1239

"outputSymlinks": [ # New in v2.1: this field will only be populated if the command

1240

# `output_paths` field was used, and not the pre v2.1 `output_files` or

1241

# `output_directories` fields.

1242

# The output paths of the action that are symbolic links to other paths. Those

1243

# may be links to other outputs, or inputs, or even absolute paths

1244

# outside of the working directory, if the server supports

1245

# SymlinkAbsolutePathStrategy.ALLOWED.

1246

# A single entry for each output requested in `output_paths`

1247

# field of the Action, if the corresponding path existed after

1248

# the action completed and was a symbolic link.

1249

#

1250

# If the action does not produce a requested output, then that output

1251

# will be omitted from the list. The server is free to arrange the output

1252

# list as desired; clients MUST NOT assume that the output list is sorted.

1253

{ # An `OutputSymlink` is similar to a

1254

# Symlink, but it is used as an

1255

# output in an `ActionResult`.

1256

#

1257

# `OutputSymlink` is binary-compatible with `SymlinkNode`.

1258

"path": "A String", # The full path of the symlink relative to the working directory, including the

1259

# filename. The path separator is a forward slash `/`. Since this is a

1260

# relative path, it MUST NOT begin with a leading forward slash.

1261

"target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.

1262

# The target path can be relative to the parent directory of the symlink or

1263

# it can be an absolute path starting with `/`. Support for absolute paths

1264

# can be checked using the Capabilities

1265

# API. The canonical form forbids the substrings `/./` and `//` in the target

1266

# path. `..` components are allowed anywhere in the target path.

1267

"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the

1268

# Action.

1269

{ # A single property for FileNodes,

1270

# DirectoryNodes, and

1271

# SymlinkNodes. The server is

1272

# responsible for specifying the property `name`s that it accepts. If

1273

# permitted by the server, the same `name` may occur multiple times.

1274

"name": "A String", # The property name.

1275

"value": "A String", # The property value.

},

],

},

],

"outputDirectorySymlinks": [ # The output directories of the action that are symbolic links to other

1281

# directories. Those may be links to other output directories, or input

1282

# directories, or even absolute paths outside of the working directory,

1283

# if the server supports

1284

# SymlinkAbsolutePathStrategy.ALLOWED.

1285

# For each output directory requested in the `output_directories` field of

1286

# the Action, if the directory existed after the action completed, a

1287

# single entry will be present either in this field, or in the

1288

# `output_directories` field, if the directory was not a symbolic link.

1289

#

1290

# If an output of the same name was found, but was a symbolic link to a file

1291

# instead of a directory, the server will return a FAILED_PRECONDITION.

1292

# If the action does not produce the requested output, then that output

1293

# will be omitted from the list. The server is free to arrange the output

1294

# list as desired; clients MUST NOT assume that the output list is sorted.

1295

#

1296

# DEPRECATED as of v2.1. Servers that wish to be compatible with v2.0 API

1297

# should still populate this field in addition to `output_symlinks`.

1298

{ # An `OutputSymlink` is similar to a

1299

# Symlink, but it is used as an

1300

# output in an `ActionResult`.

1301

#

1302

# `OutputSymlink` is binary-compatible with `SymlinkNode`.

1303

"path": "A String", # The full path of the symlink relative to the working directory, including the

1304

# filename. The path separator is a forward slash `/`. Since this is a

1305

# relative path, it MUST NOT begin with a leading forward slash.

1306

"target": "A String", # The target path of the symlink. The path separator is a forward slash `/`.

1307

# The target path can be relative to the parent directory of the symlink or

1308

# it can be an absolute path starting with `/`. Support for absolute paths

1309

# can be checked using the Capabilities

1310

# API. The canonical form forbids the substrings `/./` and `//` in the target

1311

# path. `..` components are allowed anywhere in the target path.

1312

"nodeProperties": [ # The supported node properties of the OutputSymlink, if requested by the

1313

# Action.

1314

{ # A single property for FileNodes,

1315

# DirectoryNodes, and

1316

# SymlinkNodes. The server is

1317

# responsible for specifying the property `name`s that it accepts. If

1318

# permitted by the server, the same `name` may occur multiple times.

1319

"name": "A String", # The property name.

1320

"value": "A String", # The property value.

},

],

},

],

"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

1326

# can be retrieved from the

1327

# ContentAddressableStorage.

1328

# and its hash. The hash algorithm to use is defined by the server.

1329

#

1330

# The size is considered to be an integral part of the digest and cannot be

1331

# separated. That is, even if the `hash` field is correctly specified but

1332

# `size_bytes` is not, the server MUST reject the request.

1333

#

1334

# The reason for including the size in the digest is as follows: in a great

1335

# many cases, the server needs to know the size of the blob it is about to work

1336

# with prior to starting an operation with it, such as flattening Merkle tree

1337

# structures or streaming it to a worker. Technically, the server could

1338

# implement a separate metadata store, but this results in a significantly more

1339

# complicated implementation as opposed to having the client specify the size

1340

# up-front (or storing the size along with the digest in every message where

1341

# digests are embedded). This does mean that the API leaks some implementation

1342

# details of (what we consider to be) a reasonable server implementation, but

1343

# we consider this to be a worthwhile tradeoff.

1344

#

1345

# When a `Digest` is used to refer to a proto message, it always refers to the

1346

# message in binary encoded form. To ensure consistent hashing, clients and

1347

# servers MUST ensure that they serialize messages according to the following

1348

# rules, even if there are alternate valid encodings for the same message:

1349

#

1350

# * Fields are serialized in tag order.

1351

# * There are no unknown fields.

1352

# * There are no duplicate fields.

1353

# * Fields are serialized according to the default semantics for their type.

1354

#

1355

# Most protocol buffer implementations will always follow these rules when

1356

# serializing, but care should be taken to avoid shortcuts. For instance,

1357

# concatenating two messages to merge them may produce duplicate fields.

1358

"sizeBytes": "A String", # The size of the blob, in bytes.

1359

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

1360

# exactly 64 characters long.

1361

},

1362

"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

1363

# can be retrieved from the

1364

# ContentAddressableStorage.

1365

# and its hash. The hash algorithm to use is defined by the server.

1366

#

1367

# The size is considered to be an integral part of the digest and cannot be

1368

# separated. That is, even if the `hash` field is correctly specified but

1369

# `size_bytes` is not, the server MUST reject the request.

1370

#

1371

# The reason for including the size in the digest is as follows: in a great

1372

# many cases, the server needs to know the size of the blob it is about to work

1373

# with prior to starting an operation with it, such as flattening Merkle tree

1374

# structures or streaming it to a worker. Technically, the server could

1375

# implement a separate metadata store, but this results in a significantly more

1376

# complicated implementation as opposed to having the client specify the size

1377

# up-front (or storing the size along with the digest in every message where

1378

# digests are embedded). This does mean that the API leaks some implementation

1379

# details of (what we consider to be) a reasonable server implementation, but

1380

# we consider this to be a worthwhile tradeoff.

1381

#

1382

# When a `Digest` is used to refer to a proto message, it always refers to the

1383

# message in binary encoded form. To ensure consistent hashing, clients and

1384

# servers MUST ensure that they serialize messages according to the following

1385

# rules, even if there are alternate valid encodings for the same message:

1386

#

1387

# * Fields are serialized in tag order.

1388

# * There are no unknown fields.

1389

# * There are no duplicate fields.

1390

# * Fields are serialized according to the default semantics for their type.

1391

#

1392

# Most protocol buffer implementations will always follow these rules when

1393

# serializing, but care should be taken to avoid shortcuts. For instance,

1394

# concatenating two messages to merge them may produce duplicate fields.

1395

"sizeBytes": "A String", # The size of the blob, in bytes.

1396

"hash": "A String", # The hash. In the case of SHA-256, it will always be a lowercase hex string

1397

# exactly 64 characters long.

1398

},

1399

}</pre>

Bu Sun Kim