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

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

[diff] [blame^]

78

<code><a href="#get">get(instanceName, hash, sizeBytes, inlineStdout=None, inlineStderr=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-05-27 12:20:54 -0700

[diff] [blame^]

85

<code class="details" id="get">get(instanceName, hash, sizeBytes, inlineStdout=None, inlineStderr=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-27 12:20:54 -0700

[diff] [blame^]

108

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

109

ActionResult message.

Bu Sun Kim

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

[diff] [blame]

110

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]

111

ActionResult message.

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

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

[diff] [blame]

142

#

Bu Sun Kim

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

[diff] [blame]

143

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

Bu Sun Kim

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

[diff] [blame]

144

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

145

# Action.

146

{ # A single property for FileNodes,

147

# DirectoryNodes, and

148

# SymlinkNodes. The server is

149

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

150

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

151

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

152

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

Bu Sun Kim

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

[diff] [blame]

153

},

Bu Sun Kim

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

[diff] [blame]

154

],

155

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

156

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

157

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

158

# can be checked using the Capabilities

159

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

160

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

Bu Sun Kim

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

[diff] [blame^]

161

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

162

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

163

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

Bu Sun Kim

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

[diff] [blame]

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

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

[diff] [blame]

187

#

Bu Sun Kim

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

[diff] [blame]

188

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

Bu Sun Kim

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

[diff] [blame]

189

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

190

# Action.

191

{ # A single property for FileNodes,

192

# DirectoryNodes, and

193

# SymlinkNodes. The server is

194

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

195

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

196

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

197

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

Bu Sun Kim

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

[diff] [blame]

198

},

Bu Sun Kim

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

[diff] [blame]

199

],

200

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

201

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

202

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

203

# can be checked using the Capabilities

204

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

205

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

Bu Sun Kim

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

[diff] [blame^]

206

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

207

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

208

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

Bu Sun Kim

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

[diff] [blame]

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

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

[diff] [blame]

354

},

Bu Sun Kim

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

Bu Sun Kim

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

[diff] [blame]

421

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

422

# Action.

423

{ # A single property for FileNodes,

424

# DirectoryNodes, and

425

# SymlinkNodes. The server is

426

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

427

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

428

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

429

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

430

},

431

],

432

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

433

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

434

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

435

# can be checked using the Capabilities

436

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

437

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

Bu Sun Kim

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

[diff] [blame^]

438

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

439

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

440

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

Bu Sun Kim

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

[diff] [blame]

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.

Bu Sun Kim

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

[diff] [blame]

463

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

464

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

465

#

466

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

467

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

468

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

469

#

470

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

471

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

472

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

473

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

474

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

475

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

476

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

477

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

478

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

479

# we consider this to be a worthwhile tradeoff.

480

#

481

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

482

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

483

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

484

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

485

#

486

# * Fields are serialized in tag order.

487

# * There are no unknown fields.

488

# * There are no duplicate fields.

489

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

490

#

491

# Most protocol buffer implementations will always follow these rules when

492

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

493

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

494

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

495

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

496

# exactly 64 characters long.

497

},

Bu Sun Kim

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

[diff] [blame^]

498

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

499

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

500

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

501

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

502

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

503

# file contents unless requested by the client in the

504

# GetActionResultRequest

505

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

506

# would cause the response to exceed message size limits.

507

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

508

{ # A single property for FileNodes,

509

# DirectoryNodes, and

510

# SymlinkNodes. The server is

511

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

512

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

513

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

514

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

515

},

516

],

Bu Sun Kim

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

[diff] [blame]

517

},

518

],

519

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

Bu Sun Kim

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

[diff] [blame^]

520

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

521

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

Bu Sun Kim

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

[diff] [blame]

522

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

Bu Sun Kim

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

[diff] [blame^]

523

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

Bu Sun Kim

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

[diff] [blame]

524

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

525

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

526

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

527

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

Bu Sun Kim

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

[diff] [blame]

528

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

Bu Sun Kim

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

[diff] [blame^]

529

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

Bu Sun Kim

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

[diff] [blame]

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.

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

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

[diff] [blame]

584

#

Bu Sun Kim

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

[diff] [blame]

585

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

Bu Sun Kim

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

[diff] [blame]

586

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

587

# Action.

588

{ # A single property for FileNodes,

589

# DirectoryNodes, and

590

# SymlinkNodes. The server is

591

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

592

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

593

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

594

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

Bu Sun Kim

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

[diff] [blame]

595

},

Bu Sun Kim

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

[diff] [blame]

596

],

597

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

598

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

599

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

600

# can be checked using the Capabilities

601

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

602

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

Bu Sun Kim

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

[diff] [blame^]

603

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

604

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

605

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

Bu Sun Kim

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

[diff] [blame]

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

Bu Sun Kim

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

[diff] [blame]

631

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

632

# Action.

633

{ # A single property for FileNodes,

634

# DirectoryNodes, and

635

# SymlinkNodes. The server is

636

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

637

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

638

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

639

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

Bu Sun Kim

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

[diff] [blame]

640

},

Bu Sun Kim

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

[diff] [blame]

641

],

642

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

643

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

644

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

645

# can be checked using the Capabilities

646

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

647

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

Bu Sun Kim

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

[diff] [blame^]

648

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

649

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

650

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

Bu Sun Kim

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

[diff] [blame]

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

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

[diff] [blame]

796

},

Bu Sun Kim

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

Bu Sun Kim

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

[diff] [blame]

863

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

864

# Action.

865

{ # A single property for FileNodes,

866

# DirectoryNodes, and

867

# SymlinkNodes. The server is

868

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

869

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

870

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

871

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

872

},

873

],

874

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

875

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

876

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

877

# can be checked using the Capabilities

878

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

879

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

Bu Sun Kim

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

[diff] [blame^]

880

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

881

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

882

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

Bu Sun Kim

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

[diff] [blame]

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.

Bu Sun Kim

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

[diff] [blame]

905

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

906

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

907

#

908

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

909

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

910

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

911

#

912

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

913

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

914

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

915

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

916

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

917

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

918

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

919

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

920

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

921

# we consider this to be a worthwhile tradeoff.

922

#

923

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

924

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

925

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

926

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

927

#

928

# * Fields are serialized in tag order.

929

# * There are no unknown fields.

930

# * There are no duplicate fields.

931

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

932

#

933

# Most protocol buffer implementations will always follow these rules when

934

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

935

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

936

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

937

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

938

# exactly 64 characters long.

939

},

Bu Sun Kim

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

[diff] [blame^]

940

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

941

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

942

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

943

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

944

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

945

# file contents unless requested by the client in the

946

# GetActionResultRequest

947

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

948

# would cause the response to exceed message size limits.

949

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

950

{ # A single property for FileNodes,

951

# DirectoryNodes, and

952

# SymlinkNodes. The server is

953

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

954

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

955

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

956

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

957

},

958

],

Bu Sun Kim

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

[diff] [blame]

959

},

960

],

961

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

Bu Sun Kim

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

[diff] [blame^]

962

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

963

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

Bu Sun Kim

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

[diff] [blame]

964

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

Bu Sun Kim

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

[diff] [blame^]

965

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

Bu Sun Kim

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

[diff] [blame]

966

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

967

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

968

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

969

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

Bu Sun Kim

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

[diff] [blame]

970

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

Bu Sun Kim

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

[diff] [blame^]

971

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

Bu Sun Kim

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

[diff] [blame]

972

},

973

}

Bu Sun Kim

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

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

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

[diff] [blame]

1010

#

Bu Sun Kim

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

[diff] [blame]

1011

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

Bu Sun Kim

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

[diff] [blame]

1012

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

1013

# Action.

1014

{ # A single property for FileNodes,

1015

# DirectoryNodes, and

1016

# SymlinkNodes. The server is

1017

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

1018

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

1019

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

1020

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

Bu Sun Kim

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

[diff] [blame]

1021

},

Bu Sun Kim

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

[diff] [blame]

1022

],

1023

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

1024

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

1025

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

1026

# can be checked using the Capabilities

1027

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

1028

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

Bu Sun Kim

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

[diff] [blame^]

1029

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

1030

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

1031

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

Bu Sun Kim

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

[diff] [blame]

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

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

[diff] [blame]

1055

#

Bu Sun Kim

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

[diff] [blame]

1056

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

Bu Sun Kim

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

[diff] [blame]

1057

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

1058

# Action.

1059

{ # A single property for FileNodes,

1060

# DirectoryNodes, and

1061

# SymlinkNodes. The server is

1062

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

1063

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

1064

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

1065

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

Bu Sun Kim

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

[diff] [blame]

1066

},

Bu Sun Kim

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

[diff] [blame]

1067

],

1068

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

1069

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

1070

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

1071

# can be checked using the Capabilities

1072

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

1073

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

Bu Sun Kim

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

[diff] [blame^]

1074

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

1075

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

1076

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

Bu Sun Kim

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

[diff] [blame]

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

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

[diff] [blame]

1222

},

Bu Sun Kim

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

Bu Sun Kim

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

[diff] [blame]

1289

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

1290

# Action.

1291

{ # A single property for FileNodes,

1292

# DirectoryNodes, and

1293

# SymlinkNodes. The server is

1294

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

1295

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

1296

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

1297

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

1298

},

1299

],

1300

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

1301

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

1302

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

1303

# can be checked using the Capabilities

1304

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

1305

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

Bu Sun Kim

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

[diff] [blame^]

1306

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

1307

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

1308

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

Bu Sun Kim

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

[diff] [blame]

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.

Bu Sun Kim

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

[diff] [blame]

1331

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

1332

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

1333

#

1334

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

1335

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

1336

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

1337

#

1338

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

1339

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

1340

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

1341

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

1342

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

1343

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

1344

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

1345

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

1346

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

1347

# we consider this to be a worthwhile tradeoff.

1348

#

1349

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

1350

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

1351

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

1352

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

1353

#

1354

# * Fields are serialized in tag order.

1355

# * There are no unknown fields.

1356

# * There are no duplicate fields.

1357

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

1358

#

1359

# Most protocol buffer implementations will always follow these rules when

1360

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

1361

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

1362

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

1363

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

1364

# exactly 64 characters long.

1365

},

Bu Sun Kim

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

[diff] [blame^]

1366

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

1367

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

1368

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

1369

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

1370

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

1371

# file contents unless requested by the client in the

1372

# GetActionResultRequest

1373

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

1374

# would cause the response to exceed message size limits.

1375

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

1376

{ # A single property for FileNodes,

1377

# DirectoryNodes, and

1378

# SymlinkNodes. The server is

1379

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

1380

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

1381

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

1382

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

1383

},

1384

],

Bu Sun Kim

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

[diff] [blame]

1385

},

1386

],

1387

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

Bu Sun Kim

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

[diff] [blame^]

1388

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

1389

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

Bu Sun Kim