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

<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

Bu Sun Kim

6502091

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

[diff] [blame^]

78

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

Bu Sun Kim

715bd7f

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

715bd7f

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

6502091

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

[diff] [blame^]

85

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

Bu Sun Kim

715bd7f

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

6502091

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

715bd7f

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

[diff] [blame]

109

ActionResult message.

110

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

111

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

112

Command message. (repeated)

Bu Sun Kim

6502091

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

[diff] [blame^]

113

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

Bu Sun Kim

715bd7f

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

[diff] [blame]

114

ActionResult message.

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

6502091

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

[diff] [blame^]

124

# Action being run.

125

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

126

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

127

# `output_directories` fields.

128

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

129

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

130

# outside of the working directory, if the server supports

131

# SymlinkAbsolutePathStrategy.ALLOWED.

132

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

133

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

134

# the action completed and was a symbolic link.

135

#

136

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

137

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

138

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

139

{ # An `OutputSymlink` is similar to a

140

# Symlink, but it is used as an

141

# output in an `ActionResult`.

Bu Sun Kim

715bd7f

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

[diff] [blame]

142

#

Bu Sun Kim

6502091

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

[diff] [blame^]

143

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

144

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

145

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

146

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

147

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

148

# Action.

149

{ # A single property for FileNodes,

150

# DirectoryNodes, and

151

# SymlinkNodes. The server is

152

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

153

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

154

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

155

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

Bu Sun Kim

715bd7f

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

[diff] [blame]

156

},

Bu Sun Kim

6502091

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

[diff] [blame^]

157

],

158

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

159

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

160

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

161

# can be checked using the Capabilities

162

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

163

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

164

},

165

],

166

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

167

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

168

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

169

# if the server supports

170

# SymlinkAbsolutePathStrategy.ALLOWED.

171

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

172

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

173

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

174

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

175

#

176

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

177

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

178

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

179

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

180

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

181

#

182

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

183

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

184

{ # An `OutputSymlink` is similar to a

185

# Symlink, but it is used as an

186

# output in an `ActionResult`.

Bu Sun Kim

715bd7f

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

[diff] [blame]

187

#

Bu Sun Kim

6502091

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

[diff] [blame^]

188

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

189

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

190

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

191

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

192

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

193

# Action.

194

{ # A single property for FileNodes,

195

# DirectoryNodes, and

196

# SymlinkNodes. The server is

197

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

198

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

199

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

200

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

Bu Sun Kim

715bd7f

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

[diff] [blame]

201

},

Bu Sun Kim

6502091

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

[diff] [blame^]

202

],

203

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

204

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

205

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

206

# can be checked using the Capabilities

207

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

208

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

209

},

210

],

211

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

212

# stderr unless requested by the client in the

213

# GetActionResultRequest

214

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

215

# would cause the response to exceed message size limits.

216

"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

217

# can be retrieved from the

218

# ContentAddressableStorage.

219

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

220

#

221

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

222

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

223

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

224

#

225

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

226

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

227

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

228

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

229

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

230

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

231

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

232

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

233

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

234

# we consider this to be a worthwhile tradeoff.

235

#

236

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

237

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

238

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

239

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

240

#

241

# * Fields are serialized in tag order.

242

# * There are no unknown fields.

243

# * There are no duplicate fields.

244

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

245

#

246

# Most protocol buffer implementations will always follow these rules when

247

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

248

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

249

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

250

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

251

# exactly 64 characters long.

252

},

253

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

254

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

255

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

256

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

257

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

258

# Tree message containing the

259

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

260

# output_directories member.

261

#

262

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

263

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

264

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

265

# output_directory will contain (hashes shortened for readability):

266

#

267

# ```json

268

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

305

# size: 1294,

306

# },

307

# is_executable: true

# }

# ]

# }

# }

# ```

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

314

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

315

# server will return a FAILED_PRECONDITION.

316

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

317

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

318

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

319

# Tree proto containing the

320

# directory's contents.

321

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

322

#

323

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

324

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

325

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

326

#

327

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

328

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

329

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

330

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

331

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

332

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

333

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

334

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

335

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

336

# we consider this to be a worthwhile tradeoff.

337

#

338

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

339

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

340

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

341

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

342

#

343

# * Fields are serialized in tag order.

344

# * There are no unknown fields.

345

# * There are no duplicate fields.

346

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

347

#

348

# Most protocol buffer implementations will always follow these rules when

349

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

350

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

351

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

352

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

353

# exactly 64 characters long.

Bu Sun Kim

715bd7f

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

[diff] [blame]

354

},

Bu Sun Kim

6502091

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

[diff] [blame^]

355

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

356

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

357

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

358

# and it denotes the entire working directory.

359

},

360

],

361

"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

362

# can be retrieved from the

363

# ContentAddressableStorage.

364

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

365

#

366

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

367

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

368

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

369

#

370

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

371

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

372

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

373

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

374

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

375

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

376

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

377

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

378

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

379

# we consider this to be a worthwhile tradeoff.

380

#

381

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

382

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

383

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

384

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

385

#

386

# * Fields are serialized in tag order.

387

# * There are no unknown fields.

388

# * There are no duplicate fields.

389

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

390

#

391

# Most protocol buffer implementations will always follow these rules when

392

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

393

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

394

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

395

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

396

# exactly 64 characters long.

397

},

398

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

399

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

400

# outside of the working directory, if the server supports

401

# SymlinkAbsolutePathStrategy.ALLOWED.

402

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

403

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

404

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

405

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

406

#

407

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

408

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

409

# server will return a FAILED_PRECONDITION.

410

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

411

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

412

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

413

#

414

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

415

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

416

{ # An `OutputSymlink` is similar to a

417

# Symlink, but it is used as an

418

# output in an `ActionResult`.

419

#

420

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

421

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

422

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

423

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

424

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

425

# Action.

426

{ # A single property for FileNodes,

427

# DirectoryNodes, and

428

# SymlinkNodes. The server is

429

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

430

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

431

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

432

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

433

},

434

],

435

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

436

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

437

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

438

# can be checked using the Capabilities

439

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

440

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

441

},

442

],

443

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

444

# stdout unless requested by the client in the

445

# GetActionResultRequest

446

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

447

# would cause the response to exceed message size limits.

448

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

449

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

450

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

451

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

452

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

453

#

454

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

455

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

456

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

457

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

458

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

459

{ # An `OutputFile` is similar to a

460

# FileNode, but it is used as an

461

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

462

# only a name.

463

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

464

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

465

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

466

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

467

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

468

# file contents unless requested by the client in the

469

# GetActionResultRequest

470

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

471

# would cause the response to exceed message size limits.

472

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

473

{ # A single property for FileNodes,

474

# DirectoryNodes, and

475

# SymlinkNodes. The server is

476

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

477

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

478

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

479

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

480

},

481

],

482

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

483

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

484

#

485

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

486

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

487

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

488

#

489

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

490

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

491

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

492

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

493

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

494

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

495

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

496

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

497

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

498

# we consider this to be a worthwhile tradeoff.

499

#

500

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

501

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

502

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

503

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

504

#

505

# * Fields are serialized in tag order.

506

# * There are no unknown fields.

507

# * There are no duplicate fields.

508

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

509

#

510

# Most protocol buffer implementations will always follow these rules when

511

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

512

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

513

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

514

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

515

# exactly 64 characters long.

},

},

],

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

520

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

521

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

522

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

523

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

524

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

525

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

526

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

527

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

528

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

529

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

530

},

531

}</pre>

Bu Sun Kim

715bd7f

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

715bd7f

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

715bd7f

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

6502091

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

[diff] [blame^]

566

# Action being run.

567

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

568

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

569

# `output_directories` fields.

570

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

571

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

572

# outside of the working directory, if the server supports

573

# SymlinkAbsolutePathStrategy.ALLOWED.

574

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

575

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

576

# the action completed and was a symbolic link.

577

#

578

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

579

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

580

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

581

{ # An `OutputSymlink` is similar to a

582

# Symlink, but it is used as an

583

# output in an `ActionResult`.

Bu Sun Kim

715bd7f

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

[diff] [blame]

584

#

Bu Sun Kim

6502091

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

[diff] [blame^]

585

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

586

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

587

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

588

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

589

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

590

# Action.

591

{ # A single property for FileNodes,

592

# DirectoryNodes, and

593

# SymlinkNodes. The server is

594

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

595

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

596

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

597

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

Bu Sun Kim

715bd7f

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

[diff] [blame]

598

},

Bu Sun Kim

6502091

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

[diff] [blame^]

599

],

600

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

601

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

602

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

603

# can be checked using the Capabilities

604

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

605

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

606

},

607

],

608

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

609

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

610

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

611

# if the server supports

612

# SymlinkAbsolutePathStrategy.ALLOWED.

613

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

614

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

615

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

616

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

617

#

618

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

619

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

620

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

621

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

622

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

623

#

624

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

625

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

626

{ # An `OutputSymlink` is similar to a

627

# Symlink, but it is used as an

628

# output in an `ActionResult`.

629

#

630

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

631

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

632

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

633

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

634

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

635

# Action.

636

{ # A single property for FileNodes,

637

# DirectoryNodes, and

638

# SymlinkNodes. The server is

639

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

640

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

641

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

642

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

Bu Sun Kim

715bd7f

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

[diff] [blame]

643

},

Bu Sun Kim

6502091

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

[diff] [blame^]

644

],

645

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

646

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

647

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

648

# can be checked using the Capabilities

649

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

650

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

651

},

652

],

653

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

654

# stderr unless requested by the client in the

655

# GetActionResultRequest

656

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

657

# would cause the response to exceed message size limits.

658

"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

659

# can be retrieved from the

660

# ContentAddressableStorage.

661

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

662

#

663

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

664

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

665

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

666

#

667

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

668

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

669

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

670

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

671

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

672

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

673

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

674

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

675

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

676

# we consider this to be a worthwhile tradeoff.

677

#

678

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

679

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

680

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

681

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

682

#

683

# * Fields are serialized in tag order.

684

# * There are no unknown fields.

685

# * There are no duplicate fields.

686

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

687

#

688

# Most protocol buffer implementations will always follow these rules when

689

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

690

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

691

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

692

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

693

# exactly 64 characters long.

694

},

695

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

696

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

697

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

698

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

699

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

700

# Tree message containing the

701

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

702

# output_directories member.

703

#

704

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

705

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

706

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

707

# output_directory will contain (hashes shortened for readability):

708

#

709

# ```json

710

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

747

# size: 1294,

748

# },

749

# is_executable: true

# }

# ]

# }

# }

# ```

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

756

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

757

# server will return a FAILED_PRECONDITION.

758

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

759

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

760

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

761

# Tree proto containing the

762

# directory's contents.

763

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

764

#

765

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

766

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

767

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

768

#

769

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

770

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

771

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

772

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

773

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

774

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

775

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

776

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

777

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

778

# we consider this to be a worthwhile tradeoff.

779

#

780

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

781

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

782

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

783

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

784

#

785

# * Fields are serialized in tag order.

786

# * There are no unknown fields.

787

# * There are no duplicate fields.

788

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

789

#

790

# Most protocol buffer implementations will always follow these rules when

791

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

792

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

793

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

794

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

795

# exactly 64 characters long.

Bu Sun Kim

715bd7f

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

[diff] [blame]

796

},

Bu Sun Kim

6502091

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

[diff] [blame^]

797

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

798

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

799

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

800

# and it denotes the entire working directory.

801

},

802

],

803

"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

804

# can be retrieved from the

805

# ContentAddressableStorage.

806

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

807

#

808

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

809

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

810

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

811

#

812

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

813

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

814

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

815

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

816

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

817

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

818

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

819

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

820

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

821

# we consider this to be a worthwhile tradeoff.

822

#

823

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

824

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

825

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

826

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

827

#

828

# * Fields are serialized in tag order.

829

# * There are no unknown fields.

830

# * There are no duplicate fields.

831

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

832

#

833

# Most protocol buffer implementations will always follow these rules when

834

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

835

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

836

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

837

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

838

# exactly 64 characters long.

839

},

840

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

841

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

842

# outside of the working directory, if the server supports

843

# SymlinkAbsolutePathStrategy.ALLOWED.

844

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

845

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

846

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

847

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

848

#

849

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

850

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

851

# server will return a FAILED_PRECONDITION.

852

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

853

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

854

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

855

#

856

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

857

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

858

{ # An `OutputSymlink` is similar to a

859

# Symlink, but it is used as an

860

# output in an `ActionResult`.

861

#

862

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

863

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

864

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

865

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

866

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

867

# Action.

868

{ # A single property for FileNodes,

869

# DirectoryNodes, and

870

# SymlinkNodes. The server is

871

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

872

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

873

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

874

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

875

},

876

],

877

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

878

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

879

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

880

# can be checked using the Capabilities

881

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

882

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

883

},

884

],

885

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

886

# stdout unless requested by the client in the

887

# GetActionResultRequest

888

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

889

# would cause the response to exceed message size limits.

890

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

891

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

892

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

893

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

894

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

895

#

896

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

897

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

898

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

899

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

900

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

901

{ # An `OutputFile` is similar to a

902

# FileNode, but it is used as an

903

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

904

# only a name.

905

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

906

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

907

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

908

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

909

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

910

# file contents unless requested by the client in the

911

# GetActionResultRequest

912

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

913

# would cause the response to exceed message size limits.

914

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

915

{ # A single property for FileNodes,

916

# DirectoryNodes, and

917

# SymlinkNodes. The server is

918

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

919

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

920

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

921

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

922

},

923

],

924

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

925

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

926

#

927

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

928

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

929

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

930

#

931

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

932

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

933

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

934

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

935

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

936

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

937

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

938

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

939

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

940

# we consider this to be a worthwhile tradeoff.

941

#

942

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

943

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

944

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

945

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

946

#

947

# * Fields are serialized in tag order.

948

# * There are no unknown fields.

949

# * There are no duplicate fields.

950

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

951

#

952

# Most protocol buffer implementations will always follow these rules when

953

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

954

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

955

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

956

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

957

# exactly 64 characters long.

},

},

],

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

962

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

963

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

964

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

965

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

966

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

967

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

968

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

969

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

970

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

971

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

972

},

973

}

Bu Sun Kim

715bd7f

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

[diff] [blame]

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

Bu Sun Kim

6502091

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

[diff] [blame^]

992

# Action being run.

993

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

994

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

995

# `output_directories` fields.

996

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

997

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

998

# outside of the working directory, if the server supports

999

# SymlinkAbsolutePathStrategy.ALLOWED.

1000

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

1001

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

1002

# the action completed and was a symbolic link.

1003

#

1004

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

1005

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

1006

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

1007

{ # An `OutputSymlink` is similar to a

1008

# Symlink, but it is used as an

1009

# output in an `ActionResult`.

Bu Sun Kim

715bd7f

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

[diff] [blame]

1010

#

Bu Sun Kim

6502091

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

[diff] [blame^]

1011

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

1012

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

1013

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

1014

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

1015

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

1016

# Action.

1017

{ # A single property for FileNodes,

1018

# DirectoryNodes, and

1019

# SymlinkNodes. The server is

1020

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

1021

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

1022

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

1023

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

Bu Sun Kim

715bd7f

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

[diff] [blame]

1024

},

Bu Sun Kim

6502091

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

[diff] [blame^]

1025

],

1026

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

1027

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

1028

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

1029

# can be checked using the Capabilities

1030

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

1031

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

1032

},

1033

],

1034

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

1035

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

1036

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

1037

# if the server supports

1038

# SymlinkAbsolutePathStrategy.ALLOWED.

1039

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

1040

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

1041

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

1042

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

1043

#

1044

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

1045

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

1046

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

1047

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

1048

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

1049

#

1050

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

1051

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

1052

{ # An `OutputSymlink` is similar to a

1053

# Symlink, but it is used as an

1054

# output in an `ActionResult`.

Bu Sun Kim

715bd7f

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

[diff] [blame]

1055

#

Bu Sun Kim

6502091

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

[diff] [blame^]

1056

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

1057

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

1058

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

1059

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

1060

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

1061

# Action.

1062

{ # A single property for FileNodes,

1063

# DirectoryNodes, and

1064

# SymlinkNodes. The server is

1065

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

1066

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

1067

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

1068

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

Bu Sun Kim

715bd7f

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

[diff] [blame]

1069

},

Bu Sun Kim

6502091

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

[diff] [blame^]

1070

],

1071

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

1072

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

1073

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

1074

# can be checked using the Capabilities

1075

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

1076

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

1077

},

1078

],

1079

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

1080

# stderr unless requested by the client in the

1081

# GetActionResultRequest

1082

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

1083

# would cause the response to exceed message size limits.

1084

"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

1085

# can be retrieved from the

1086

# ContentAddressableStorage.

1087

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

1088

#

1089

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

1090

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

1091

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

1092

#

1093

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

1094

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

1095

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

1096

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

1097

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

1098

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

1099

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

1100

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

1101

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

1102

# we consider this to be a worthwhile tradeoff.

1103

#

1104

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

1105

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

1106

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

1107

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

1108

#

1109

# * Fields are serialized in tag order.

1110

# * There are no unknown fields.

1111

# * There are no duplicate fields.

1112

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

1113

#

1114

# Most protocol buffer implementations will always follow these rules when

1115

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

1116

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

1117

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

1118

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

1119

# exactly 64 characters long.

1120

},

1121

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

1122

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

1123

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

1124

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

1125

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

1126

# Tree message containing the

1127

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

1128

# output_directories member.

1129

#

1130

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

1131

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

1132

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

1133

# output_directory will contain (hashes shortened for readability):

1134

#

1135

# ```json

1136

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

1173

# size: 1294,

1174

# },

1175

# is_executable: true

# }

# ]

# }

# }

# ```

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

1182

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

1183

# server will return a FAILED_PRECONDITION.

1184

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

1185

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

1186

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

1187

# Tree proto containing the

1188

# directory's contents.

1189

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

1190

#

1191

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

1192

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

1193

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

1194

#

1195

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

1196

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

1197

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

1198

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

1199

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

1200

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

1201

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

1202

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

1203

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

1204

# we consider this to be a worthwhile tradeoff.

1205

#

1206

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

1207

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

1208

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

1209

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

1210

#

1211

# * Fields are serialized in tag order.

1212

# * There are no unknown fields.

1213

# * There are no duplicate fields.

1214

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

1215

#

1216

# Most protocol buffer implementations will always follow these rules when

1217

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

1218

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

1219

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

1220

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

1221

# exactly 64 characters long.

Bu Sun Kim

715bd7f

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

[diff] [blame]

1222

},

Bu Sun Kim

6502091

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

[diff] [blame^]

1223

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

1224

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

1225

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

1226

# and it denotes the entire working directory.

1227

},

1228

],

1229

"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

1230

# can be retrieved from the

1231

# ContentAddressableStorage.

1232

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

1233

#

1234

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

1235

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

1236

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

1237

#

1238

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

1239

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

1240

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

1241

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

1242

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

1243

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

1244

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

1245

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

1246

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

1247

# we consider this to be a worthwhile tradeoff.

1248

#

1249

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

1250

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

1251

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

1252

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

1253

#

1254

# * Fields are serialized in tag order.

1255

# * There are no unknown fields.

1256

# * There are no duplicate fields.

1257

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

1258

#

1259

# Most protocol buffer implementations will always follow these rules when

1260

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

1261

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

1262

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

1263

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

1264

# exactly 64 characters long.

1265

},

1266

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

1267

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

1268

# outside of the working directory, if the server supports

1269

# SymlinkAbsolutePathStrategy.ALLOWED.

1270

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

1271

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

1272

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

1273

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

1274

#

1275

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

1276

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

1277

# server will return a FAILED_PRECONDITION.

1278

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

1279

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

1280

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

1281

#

1282

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

1283

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

1284

{ # An `OutputSymlink` is similar to a

1285

# Symlink, but it is used as an

1286

# output in an `ActionResult`.

1287

#

1288

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

1289

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

1290

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

1291

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

1292

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

1293

# Action.

1294

{ # A single property for FileNodes,

1295

# DirectoryNodes, and

1296

# SymlinkNodes. The server is

1297

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

1298

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

1299

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

1300

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

1301

},

1302

],

1303

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

1304

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

1305

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

1306

# can be checked using the Capabilities

1307

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

1308

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

1309

},

1310

],

1311

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

1312

# stdout unless requested by the client in the

1313

# GetActionResultRequest

1314

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

1315

# would cause the response to exceed message size limits.

1316

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

1317

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

1318

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

1319

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

1320

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

1321

#

1322

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

1323

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

1324

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

1325

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

1326

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

1327

{ # An `OutputFile` is similar to a

1328

# FileNode, but it is used as an

1329

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

1330

# only a name.

1331

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

1332

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

1333

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

1334

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

1335

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

1336

# file contents unless requested by the client in the

1337

# GetActionResultRequest

1338

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

1339

# would cause the response to exceed message size limits.

1340

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

1341

{ # A single property for FileNodes,

1342

# DirectoryNodes, and

1343

# SymlinkNodes. The server is

1344

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

1345

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

1346

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

1347

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

1348

},

1349

],

1350

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

1351

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

1352

#

1353

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

1354

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

1355

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

1356

#

1357

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

1358

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

1359

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

1360

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

1361

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

1362

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

1363

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

1364

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

1365

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

1366

# we consider this to be a worthwhile tradeoff.

1367

#

1368

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

1369

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

1370

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

1371

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

1372

#

1373

# * Fields are serialized in tag order.

1374

# * There are no unknown fields.

1375

# * There are no duplicate fields.

1376

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

1377

#

1378

# Most protocol buffer implementations will always follow these rules when

1379

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

1380

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

1381

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

1382

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

1383

# exactly 64 characters long.

},

},

],

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

1388

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

1389

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

1390

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

1391

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

1392

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

1393

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

1394

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

1395

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

1396

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

1397

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

1398

},

1399

}</pre>

Bu Sun Kim

715bd7f

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

[diff] [blame]

1400

</div>

1401

1402

</body></html>