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

"digest": { # A content digest. A digest for a given blob consists of the size of the blob # The digest of the blob. This MUST be the digest of `data`.

281

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

282

# SHOULD use SHA-256.

283

#

284

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

285

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

286

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

287

#

288

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

289

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

290

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

291

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

292

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

293

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

294

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

295

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

296

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

297

# we consider this to be a worthwhile tradeoff.

298

#

299

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

300

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

301

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

302

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

303

#

304

# * Fields are serialized in tag order.

305

# * There are no unknown fields.

306

# * There are no duplicate fields.

307

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

308

#

309

# Most protocol buffer implementations will always follow these rules when

310

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

311

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

312

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

313

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

314

# exactly 64 characters long.

},

},

],

}

x__xgafv: string, V1 error format.

Allowed values

1 - v1 error format

2 - v2 error format

Returns:

An object of the form:

327

328

{ # A response message for

329

# ContentAddressableStorage.BatchUpdateBlobs.

330

"responses": [ # The responses to the requests.

331

{ # A response corresponding to a single blob that the client tried to upload.

332

"status": { # The `Status` type defines a logical error model that is suitable for # The result of attempting to upload that blob.

333

# different programming environments, including REST APIs and RPC APIs. It is

334

# used by [gRPC](https://github.com/grpc). Each `Status` message contains

335

# three pieces of data: error code, error message, and error details.

336

#

337

# You can find out more about this error model and how to work with it in the

338

# [API Design Guide](https://cloud.google.com/apis/design/errors).

339

"message": "A String", # A developer-facing error message, which should be in English. Any

340

# user-facing error message should be localized and sent in the

341

# google.rpc.Status.details field, or localized by the client.

342

"code": 42, # The status code, which should be an enum value of google.rpc.Code.

343

"details": [ # A list of messages that carry the error details. There is a common set of

344

# message types for APIs to use.

345

{

346

"a_key": "", # Properties of the object. Contains field @type with type URL.

},

],

},

"digest": { # A content digest. A digest for a given blob consists of the size of the blob # The blob digest to which this response corresponds.

351

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

352

# SHOULD use SHA-256.

353

#

354

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

355

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

356

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

357

#

358

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

359

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

360

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

361

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

362

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

363

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

364

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

365

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

366

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

367

# we consider this to be a worthwhile tradeoff.

368

#

369

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

370

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

371

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

372

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

373

#

374

# * Fields are serialized in tag order.

375

# * There are no unknown fields.

376

# * There are no duplicate fields.

377

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

378

#

379

# Most protocol buffer implementations will always follow these rules when

380

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

381

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

382

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

383

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

384

# exactly 64 characters long.

},

},

],

}</pre>

</div>

<code class="details" id="findMissing">findMissing(instanceName, body, x__xgafv=None)</code>

393

<pre>Determine if blobs are present in the CAS.

394

395

Clients can use this API before uploading blobs to determine which ones are

396

already present in the CAS and do not need to be uploaded again.

397

398

There are no method-specific errors.

399

400

Args:

401

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

402

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

403

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

404

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

405

omitted. (required)

406

body: object, The request body. (required)

407

The object takes the form of:

408

409

{ # A request message for

410

# ContentAddressableStorage.FindMissingBlobs.

411

"blobDigests": [ # A list of the blobs to check.

412

{ # A content digest. A digest for a given blob consists of the size of the blob

413

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

414

# SHOULD use SHA-256.

415

#

416

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

417

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

418

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

419

#

420

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

421

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

422

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

423

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

424

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

425

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

426

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

427

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

428

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

429

# we consider this to be a worthwhile tradeoff.

430

#

431

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

432

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

433

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

434

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

435

#

436

# * Fields are serialized in tag order.

437

# * There are no unknown fields.

438

# * There are no duplicate fields.

439

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

440

#

441

# Most protocol buffer implementations will always follow these rules when

442

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

443

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

444

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

445

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

446

# exactly 64 characters long.

},

],

}

x__xgafv: string, V1 error format.

Allowed values

1 - v1 error format

2 - v2 error format

Returns:

An object of the form:

458

459

{ # A response message for

460

# ContentAddressableStorage.FindMissingBlobs.

461

"missingBlobDigests": [ # A list of the blobs requested *not* present in the storage.

462

{ # A content digest. A digest for a given blob consists of the size of the blob

463

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

464

# SHOULD use SHA-256.

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.

},

],

}</pre>

</div>

<code class="details" id="getTree">getTree(instanceName, hash, sizeBytes, pageSize=None, pageToken=None, x__xgafv=None)</code>

504

<pre>Fetch the entire directory tree rooted at a node.

505

506

This request must be targeted at a

507

Directory stored in the

508

ContentAddressableStorage

509

(CAS). The server will enumerate the `Directory` tree recursively and

510

return every node descended from the root.

511

512

The GetTreeRequest.page_token parameter can be used to skip ahead in

513

the stream (e.g. when retrying a partially completed and aborted request),

514

by setting it to a value taken from GetTreeResponse.next_page_token of the

515

last successfully processed GetTreeResponse).

516

517

The exact traversal order is unspecified and, unless retrieving subsequent

518

pages from an earlier request, is not guaranteed to be stable across

519

multiple invocations of `GetTree`.

520

521

If part of the tree is missing from the CAS, the server will return the

522

portion present and omit the rest.

523

524

* `NOT_FOUND`: The requested tree root is not present in the CAS.

525

526

Args:

527

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

528

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

529

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

530

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

531

omitted. (required)

532

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

533

exactly 64 characters long. (required)

534

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

535

pageSize: integer, A maximum page size to request. If present, the server will request no more

536

than this many items. Regardless of whether a page size is specified, the

537

server may place its own limit on the number of items to be returned and

538

require the client to retrieve more items using a subsequent request.

539

pageToken: string, A page token, which must be a value received in a previous

540

GetTreeResponse.

541

If present, the server will use it to return the following page of results.

542

x__xgafv: string, V1 error format.

Allowed values

1 - v1 error format

2 - v2 error format

Returns:

An object of the form:

549

550

{ # A response message for

551

# ContentAddressableStorage.GetTree.

552

"nextPageToken": "A String", # If present, signifies that there are more results which the client can

553

# retrieve by passing this as the page_token in a subsequent

554

# request.

555

# If empty, signifies that this is the last page of results.

556

"directories": [ # The directories descended from the requested root.

557

{ # A `Directory` represents a directory node in a file tree, containing zero or

558

# more children FileNodes,

559

# DirectoryNodes and

560

# SymlinkNodes.

561

# Each `Node` contains its name in the directory, either the digest of its

562

# content (either a file blob or a `Directory` proto) or a symlink target, as

563

# well as possibly some metadata about the file or directory.

564

#

565

# In order to ensure that two equivalent directory trees hash to the same

566

# value, the following restrictions MUST be obeyed when constructing a

567

# a `Directory`:

568

#

569

# * Every child in the directory must have a path of exactly one segment.

570

# Multiple levels of directory hierarchy may not be collapsed.

571

# * Each child in the directory must have a unique path segment (file name).

572

# Note that while the API itself is case-sensitive, the environment where

573

# the Action is executed may or may not be case-sensitive. That is, it is

574

# legal to call the API with a Directory that has both "Foo" and "foo" as

575

# children, but the Action may be rejected by the remote system upon

576

# execution.

577

# * The files, directories and symlinks in the directory must each be sorted

578

# in lexicographical order by path. The path strings must be sorted by code

579

# point, equivalently, by UTF-8 bytes.

580

#

581

# A `Directory` that obeys the restrictions is said to be in canonical form.

582

#

583

# As an example, the following could be used for a file named `bar` and a

584

# directory named `foo` with an executable file named `baz` (hashes shortened

# for readability):

#

# ```json

# // (Directory proto)

# {

# files: [

# {

# name: "bar",

# digest: {

# hash: "4a73bc9d03...",

# size: 65534

# }

# }

# ],

# directories: [

# {

# name: "foo",

# digest: {

# hash: "4cf2eda940...",

# size: 43

# }

# }

# ]

# }

#

# // (Directory proto with hash "4cf2eda940..." and size 43)

# {

# files: [

# {

# name: "baz",

# digest: {

# hash: "b2c941073e...",

617

# size: 1294,

618

# },

619

# is_executable: true

# }

# ]

# }

# ```

"symlinks": [ # The symlinks in the directory.

625

{ # A `SymlinkNode` represents a symbolic link.

626

"name": "A String", # The name of the symlink.

627

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

628

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

629

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

630

# can be checked using the Capabilities

631

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

632

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

633

},

634

],

635

"files": [ # The files in the directory.

636

{ # A `FileNode` represents a single file and associated metadata.

637

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

638

"name": "A String", # The name of the file.

639

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

640

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

641

# SHOULD use SHA-256.

642

#

643

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

644

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

645

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

646

#

647

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

648

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

649

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

650

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

651

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

652

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

653

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

654

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

655

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

656

# we consider this to be a worthwhile tradeoff.

657

#

658

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

659

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

660

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

661

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

662

#

663

# * Fields are serialized in tag order.

664

# * There are no unknown fields.

665

# * There are no duplicate fields.

666

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

667

#

668

# Most protocol buffer implementations will always follow these rules when

669

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

670

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

671

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

672

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

673

# exactly 64 characters long.

},

},

],

"directories": [ # The subdirectories in the directory.

678

{ # A `DirectoryNode` represents a child of a

679

# Directory which is itself

680

# a `Directory` and its associated metadata.

681

"name": "A String", # The name of the directory.

682

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

683

# Directory object

684

# represented. See Digest

685

# for information about how to take the digest of a proto message.

686

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

687

# SHOULD use SHA-256.

688

#

689

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

690

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

691

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

692

#

693

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

694

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

695

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

696

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

697

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

698

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

699

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

700

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

701

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

702

# we consider this to be a worthwhile tradeoff.

703

#

704

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

705

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

706

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

707

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

708

#

709

# * Fields are serialized in tag order.

710

# * There are no unknown fields.

711

# * There are no duplicate fields.

712

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

713

#

714

# Most protocol buffer implementations will always follow these rules when

715

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

716

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

717

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

718

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

719

# exactly 64 characters long.

},

},

],

},

],

}</pre>

</div>

<code class="details" id="getTree_next">getTree_next(previous_request, previous_response)</code>

730

<pre>Retrieves the next page of results.

731

732

Args:

733

previous_request: The request for the previous page. (required)

734

previous_response: The response from the request for the previous page. (required)

735

736

Returns:

737

A request object that you can call 'execute()' on to request the next

738

page. Returns None if there are no more items in the collection.

</pre>

</div>

</body></html>