-
Notifications
You must be signed in to change notification settings - Fork 118
/
remote_execution.proto
2144 lines (1927 loc) · 95.5 KB
/
remote_execution.proto
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
// Copyright 2018 The Bazel Authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
syntax = "proto3";
package build.bazel.remote.execution.v2;
import "build/bazel/semver/semver.proto";
import "google/api/annotations.proto";
import "google/longrunning/operations.proto";
import "google/protobuf/any.proto";
import "google/protobuf/duration.proto";
import "google/protobuf/timestamp.proto";
import "google/protobuf/wrappers.proto";
import "google/rpc/status.proto";
option csharp_namespace = "Build.Bazel.Remote.Execution.V2";
option go_package = "github.com/bazelbuild/remote-apis/build/bazel/remote/execution/v2;remoteexecution";
option java_multiple_files = true;
option java_outer_classname = "RemoteExecutionProto";
option java_package = "build.bazel.remote.execution.v2";
option objc_class_prefix = "REX";
// The Remote Execution API is used to execute an
// [Action][build.bazel.remote.execution.v2.Action] on the remote
// workers.
//
// As with other services in the Remote Execution API, any call may return an
// error with a [RetryInfo][google.rpc.RetryInfo] error detail providing
// information about when the client should retry the request; clients SHOULD
// respect the information provided.
service Execution {
// Execute an action remotely.
//
// In order to execute an action, the client must first upload all of the
// inputs, the
// [Command][build.bazel.remote.execution.v2.Command] to run, and the
// [Action][build.bazel.remote.execution.v2.Action] into the
// [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage].
// It then calls `Execute` with an `action_digest` referring to them. The
// server will run the action and eventually return the result.
//
// The input `Action`'s fields MUST meet the various canonicalization
// requirements specified in the documentation for their types so that it has
// the same digest as other logically equivalent `Action`s. The server MAY
// enforce the requirements and return errors if a non-canonical input is
// received. It MAY also proceed without verifying some or all of the
// requirements, such as for performance reasons. If the server does not
// verify the requirement, then it will treat the `Action` as distinct from
// another logically equivalent action if they hash differently.
//
// Returns a stream of
// [google.longrunning.Operation][google.longrunning.Operation] messages
// describing the resulting execution, with eventual `response`
// [ExecuteResponse][build.bazel.remote.execution.v2.ExecuteResponse]. The
// `metadata` on the operation is of type
// [ExecuteOperationMetadata][build.bazel.remote.execution.v2.ExecuteOperationMetadata].
//
// If the client remains connected after the first response is returned after
// the server, then updates are streamed as if the client had called
// [WaitExecution][build.bazel.remote.execution.v2.Execution.WaitExecution]
// until the execution completes or the request reaches an error. The
// operation can also be queried using [Operations
// API][google.longrunning.Operations.GetOperation].
//
// The server NEED NOT implement other methods or functionality of the
// Operations API.
//
// Errors discovered during creation of the `Operation` will be reported
// as gRPC Status errors, while errors that occurred while running the
// action will be reported in the `status` field of the `ExecuteResponse`. The
// server MUST NOT set the `error` field of the `Operation` proto.
// The possible errors include:
//
// * `INVALID_ARGUMENT`: One or more arguments are invalid.
// * `FAILED_PRECONDITION`: One or more errors occurred in setting up the
// action requested, such as a missing input or command or no worker being
// available. The client may be able to fix the errors and retry.
// * `RESOURCE_EXHAUSTED`: There is insufficient quota of some resource to run
// the action.
// * `UNAVAILABLE`: Due to a transient condition, such as all workers being
// occupied (and the server does not support a queue), the action could not
// be started. The client should retry.
// * `INTERNAL`: An internal error occurred in the execution engine or the
// worker.
// * `DEADLINE_EXCEEDED`: The execution timed out.
// * `CANCELLED`: The operation was cancelled by the client. This status is
// only possible if the server implements the Operations API CancelOperation
// method, and it was called for the current execution.
//
// In the case of a missing input or command, the server SHOULD additionally
// send a [PreconditionFailure][google.rpc.PreconditionFailure] error detail
// where, for each requested blob not present in the CAS, there is a
// `Violation` with a `type` of `MISSING` and a `subject` of
// `"blobs/{digest_function/}{hash}/{size}"` indicating the digest of the
// missing blob. The `subject` is formatted the same way as the
// `resource_name` provided to
// [ByteStream.Read][google.bytestream.ByteStream.Read], with the leading
// instance name omitted. `digest_function` MUST thus be omitted if its value
// is one of MD5, MURMUR3, SHA1, SHA256, SHA384, SHA512, or VSO.
//
// The server does not need to guarantee that a call to this method leads to
// at most one execution of the action. The server MAY execute the action
// multiple times, potentially in parallel. These redundant executions MAY
// continue to run, even if the operation is completed.
rpc Execute(ExecuteRequest) returns (stream google.longrunning.Operation) {
option (google.api.http) = { post: "/v2/{instance_name=**}/actions:execute" body: "*" };
}
// Wait for an execution operation to complete. When the client initially
// makes the request, the server immediately responds with the current status
// of the execution. The server will leave the request stream open until the
// operation completes, and then respond with the completed operation. The
// server MAY choose to stream additional updates as execution progresses,
// such as to provide an update as to the state of the execution.
//
// In addition to the cases describe for Execute, the WaitExecution method
// may fail as follows:
//
// * `NOT_FOUND`: The operation no longer exists due to any of a transient
// condition, an unknown operation name, or if the server implements the
// Operations API DeleteOperation method and it was called for the current
// execution. The client should call `Execute` to retry.
rpc WaitExecution(WaitExecutionRequest) returns (stream google.longrunning.Operation) {
option (google.api.http) = { post: "/v2/{name=operations/**}:waitExecution" body: "*" };
}
}
// The action cache API is used to query whether a given action has already been
// performed and, if so, retrieve its result. Unlike the
// [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage],
// which addresses blobs by their own content, the action cache addresses the
// [ActionResult][build.bazel.remote.execution.v2.ActionResult] by a
// digest of the encoded [Action][build.bazel.remote.execution.v2.Action]
// which produced them.
//
// The lifetime of entries in the action cache is implementation-specific, but
// the server SHOULD assume that more recently used entries are more likely to
// be used again.
//
// As with other services in the Remote Execution API, any call may return an
// error with a [RetryInfo][google.rpc.RetryInfo] error detail providing
// information about when the client should retry the request; clients SHOULD
// respect the information provided.
service ActionCache {
// Retrieve a cached execution result.
//
// Implementations SHOULD ensure that any blobs referenced from the
// [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage]
// are available at the time of returning the
// [ActionResult][build.bazel.remote.execution.v2.ActionResult] and will be
// for some period of time afterwards. The lifetimes of the referenced blobs SHOULD be increased
// if necessary and applicable.
//
// Errors:
//
// * `NOT_FOUND`: The requested `ActionResult` is not in the cache.
rpc GetActionResult(GetActionResultRequest) returns (ActionResult) {
option (google.api.http) = { get: "/v2/{instance_name=**}/actionResults/{action_digest.hash}/{action_digest.size_bytes}" };
}
// Upload a new execution result.
//
// In order to allow the server to perform access control based on the type of
// action, and to assist with client debugging, the client MUST first upload
// the [Action][build.bazel.remote.execution.v2.Execution] that produced the
// result, along with its
// [Command][build.bazel.remote.execution.v2.Command], into the
// `ContentAddressableStorage`.
//
// Server implementations MAY modify the
// `UpdateActionResultRequest.action_result` and return an equivalent value.
//
// Errors:
//
// * `INVALID_ARGUMENT`: One or more arguments are invalid.
// * `FAILED_PRECONDITION`: One or more errors occurred in updating the
// action result, such as a missing command or action.
// * `RESOURCE_EXHAUSTED`: There is insufficient storage space to add the
// entry to the cache.
rpc UpdateActionResult(UpdateActionResultRequest) returns (ActionResult) {
option (google.api.http) = { put: "/v2/{instance_name=**}/actionResults/{action_digest.hash}/{action_digest.size_bytes}" body: "action_result" };
}
}
// The CAS (content-addressable storage) is used to store the inputs to and
// outputs from the execution service. Each piece of content is addressed by the
// digest of its binary data.
//
// Most of the binary data stored in the CAS is opaque to the execution engine,
// and is only used as a communication medium. In order to build an
// [Action][build.bazel.remote.execution.v2.Action],
// however, the client will need to also upload the
// [Command][build.bazel.remote.execution.v2.Command] and input root
// [Directory][build.bazel.remote.execution.v2.Directory] for the Action.
// The Command and Directory messages must be marshalled to wire format and then
// uploaded under the hash as with any other piece of content. In practice, the
// input root directory is likely to refer to other Directories in its
// hierarchy, which must also each be uploaded on their own.
//
// For small file uploads the client should group them together and call
// [BatchUpdateBlobs][build.bazel.remote.execution.v2.ContentAddressableStorage.BatchUpdateBlobs].
//
// For large uploads, the client must use the
// [Write method][google.bytestream.ByteStream.Write] of the ByteStream API.
//
// For uncompressed data, The `WriteRequest.resource_name` is of the following form:
// `{instance_name}/uploads/{uuid}/blobs/{digest_function/}{hash}/{size}{/optional_metadata}`
//
// Where:
// * `instance_name` is an identifier used to distinguish between the various
// instances on the server. Syntax and semantics of this field are defined
// by the server; Clients must not make any assumptions about it (e.g.,
// whether it spans multiple path segments or not). If it is the empty path,
// the leading slash is omitted, so that the `resource_name` becomes
// `uploads/{uuid}/blobs/{digest_function/}{hash}/{size}{/optional_metadata}`.
// To simplify parsing, a path segment cannot equal any of the following
// keywords: `blobs`, `uploads`, `actions`, `actionResults`, `operations`,
// `capabilities` or `compressed-blobs`.
// * `uuid` is a version 4 UUID generated by the client, used to avoid
// collisions between concurrent uploads of the same data. Clients MAY
// reuse the same `uuid` for uploading different blobs.
// * `digest_function` is a lowercase string form of a `DigestFunction.Value`
// enum, indicating which digest function was used to compute `hash`. If the
// digest function used is one of MD5, MURMUR3, SHA1, SHA256, SHA384, SHA512,
// or VSO, this component MUST be omitted. In that case the server SHOULD
// infer the digest function using the length of the `hash` and the digest
// functions announced in the server's capabilities.
// * `hash` and `size` refer to the [Digest][build.bazel.remote.execution.v2.Digest]
// of the data being uploaded.
// * `optional_metadata` is implementation specific data, which clients MAY omit.
// Servers MAY ignore this metadata.
//
// Data can alternatively be uploaded in compressed form, with the following
// `WriteRequest.resource_name` form:
// `{instance_name}/uploads/{uuid}/compressed-blobs/{compressor}/{digest_function/}{uncompressed_hash}/{uncompressed_size}{/optional_metadata}`
//
// Where:
// * `instance_name`, `uuid`, `digest_function` and `optional_metadata` are
// defined as above.
// * `compressor` is a lowercase string form of a `Compressor.Value` enum
// other than `identity`, which is supported by the server and advertised in
// [CacheCapabilities.supported_compressor][build.bazel.remote.execution.v2.CacheCapabilities.supported_compressor].
// * `uncompressed_hash` and `uncompressed_size` refer to the
// [Digest][build.bazel.remote.execution.v2.Digest] of the data being
// uploaded, once uncompressed. Servers MUST verify that these match
// the uploaded data once uncompressed, and MUST return an
// `INVALID_ARGUMENT` error in the case of mismatch.
//
// Note that when writing compressed blobs, the `WriteRequest.write_offset` in
// the initial request in a stream refers to the offset in the uncompressed form
// of the blob. In subsequent requests, `WriteRequest.write_offset` MUST be the
// sum of the first request's 'WriteRequest.write_offset' and the total size of
// all the compressed data bundles in the previous requests.
// Note that this mixes an uncompressed offset with a compressed byte length,
// which is nonsensical, but it is done to fit the semantics of the existing
// ByteStream protocol.
//
// Uploads of the same data MAY occur concurrently in any form, compressed or
// uncompressed.
//
// Clients SHOULD NOT use gRPC-level compression for ByteStream API `Write`
// calls of compressed blobs, since this would compress already-compressed data.
//
// When attempting an upload, if another client has already completed the upload
// (which may occur in the middle of a single upload if another client uploads
// the same blob concurrently), the request will terminate immediately without
// error, and with a response whose `committed_size` is the value `-1` if this
// is a compressed upload, or with the full size of the uploaded file if this is
// an uncompressed upload (regardless of how much data was transmitted by the
// client). If the client completes the upload but the
// [Digest][build.bazel.remote.execution.v2.Digest] does not match, an
// `INVALID_ARGUMENT` error will be returned. In either case, the client should
// not attempt to retry the upload.
//
// Small downloads can be grouped and requested in a batch via
// [BatchReadBlobs][build.bazel.remote.execution.v2.ContentAddressableStorage.BatchReadBlobs].
//
// For large downloads, the client must use the
// [Read method][google.bytestream.ByteStream.Read] of the ByteStream API.
//
// For uncompressed data, The `ReadRequest.resource_name` is of the following form:
// `{instance_name}/blobs/{digest_function/}{hash}/{size}`
// Where `instance_name`, `digest_function`, `hash` and `size` are defined as
// for uploads.
//
// Data can alternatively be downloaded in compressed form, with the following
// `ReadRequest.resource_name` form:
// `{instance_name}/compressed-blobs/{compressor}/{digest_function/}{uncompressed_hash}/{uncompressed_size}`
//
// Where:
// * `instance_name`, `compressor` and `digest_function` are defined as for
// uploads.
// * `uncompressed_hash` and `uncompressed_size` refer to the
// [Digest][build.bazel.remote.execution.v2.Digest] of the data being
// downloaded, once uncompressed. Clients MUST verify that these match
// the downloaded data once uncompressed, and take appropriate steps in
// the case of failure such as retrying a limited number of times or
// surfacing an error to the user.
//
// When downloading compressed blobs:
// * `ReadRequest.read_offset` refers to the offset in the uncompressed form
// of the blob.
// * Servers MUST return `INVALID_ARGUMENT` if `ReadRequest.read_limit` is
// non-zero.
// * Servers MAY use any compression level they choose, including different
// levels for different blobs (e.g. choosing a level designed for maximum
// speed for data known to be incompressible).
// * Clients SHOULD NOT use gRPC-level compression, since this would compress
// already-compressed data.
//
// Servers MUST be able to provide data for all recently advertised blobs in
// each of the compression formats that the server supports, as well as in
// uncompressed form.
//
// The lifetime of entries in the CAS is implementation specific, but it SHOULD
// be long enough to allow for newly-added and recently looked-up entries to be
// used in subsequent calls (e.g. to
// [Execute][build.bazel.remote.execution.v2.Execution.Execute]).
//
// Servers MUST behave as though empty blobs are always available, even if they
// have not been uploaded. Clients MAY optimize away the uploading or
// downloading of empty blobs.
//
// As with other services in the Remote Execution API, any call may return an
// error with a [RetryInfo][google.rpc.RetryInfo] error detail providing
// information about when the client should retry the request; clients SHOULD
// respect the information provided.
service ContentAddressableStorage {
// Determine if blobs are present in the CAS.
//
// Clients can use this API before uploading blobs to determine which ones are
// already present in the CAS and do not need to be uploaded again.
//
// Servers SHOULD increase the lifetimes of the referenced blobs if necessary and
// applicable.
//
// There are no method-specific errors.
rpc FindMissingBlobs(FindMissingBlobsRequest) returns (FindMissingBlobsResponse) {
option (google.api.http) = { post: "/v2/{instance_name=**}/blobs:findMissing" body: "*" };
}
// Upload many blobs at once.
//
// The server may enforce a limit of the combined total size of blobs
// to be uploaded using this API. This limit may be obtained using the
// [Capabilities][build.bazel.remote.execution.v2.Capabilities] API.
// Requests exceeding the limit should either be split into smaller
// chunks or uploaded using the
// [ByteStream API][google.bytestream.ByteStream], as appropriate.
//
// This request is equivalent to calling a Bytestream `Write` request
// on each individual blob, in parallel. The requests may succeed or fail
// independently.
//
// Errors:
//
// * `INVALID_ARGUMENT`: The client attempted to upload more than the
// server supported limit.
//
// Individual requests may return the following errors, additionally:
//
// * `RESOURCE_EXHAUSTED`: There is insufficient disk quota to store the blob.
// * `INVALID_ARGUMENT`: The
// [Digest][build.bazel.remote.execution.v2.Digest] does not match the
// provided data.
rpc BatchUpdateBlobs(BatchUpdateBlobsRequest) returns (BatchUpdateBlobsResponse) {
option (google.api.http) = { post: "/v2/{instance_name=**}/blobs:batchUpdate" body: "*" };
}
// Download many blobs at once.
//
// The server may enforce a limit of the combined total size of blobs
// to be downloaded using this API. This limit may be obtained using the
// [Capabilities][build.bazel.remote.execution.v2.Capabilities] API.
// Requests exceeding the limit should either be split into smaller
// chunks or downloaded using the
// [ByteStream API][google.bytestream.ByteStream], as appropriate.
//
// This request is equivalent to calling a Bytestream `Read` request
// on each individual blob, in parallel. The requests may succeed or fail
// independently.
//
// Errors:
//
// * `INVALID_ARGUMENT`: The client attempted to read more than the
// server supported limit.
//
// Every error on individual read will be returned in the corresponding digest
// status.
rpc BatchReadBlobs(BatchReadBlobsRequest) returns (BatchReadBlobsResponse) {
option (google.api.http) = { post: "/v2/{instance_name=**}/blobs:batchRead" body: "*" };
}
// Fetch the entire directory tree rooted at a node.
//
// This request must be targeted at a
// [Directory][build.bazel.remote.execution.v2.Directory] stored in the
// [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage]
// (CAS). The server will enumerate the `Directory` tree recursively and
// return every node descended from the root.
//
// The GetTreeRequest.page_token parameter can be used to skip ahead in
// the stream (e.g. when retrying a partially completed and aborted request),
// by setting it to a value taken from GetTreeResponse.next_page_token of the
// last successfully processed GetTreeResponse).
//
// The exact traversal order is unspecified and, unless retrieving subsequent
// pages from an earlier request, is not guaranteed to be stable across
// multiple invocations of `GetTree`.
//
// If part of the tree is missing from the CAS, the server will return the
// portion present and omit the rest.
//
// Errors:
//
// * `NOT_FOUND`: The requested tree root is not present in the CAS.
rpc GetTree(GetTreeRequest) returns (stream GetTreeResponse) {
option (google.api.http) = { get: "/v2/{instance_name=**}/blobs/{root_digest.hash}/{root_digest.size_bytes}:getTree" };
}
}
// The Capabilities service may be used by remote execution clients to query
// various server properties, in order to self-configure or return meaningful
// error messages.
//
// The query may include a particular `instance_name`, in which case the values
// returned will pertain to that instance.
service Capabilities {
// GetCapabilities returns the server capabilities configuration of the
// remote endpoint.
// Only the capabilities of the services supported by the endpoint will
// be returned:
// * Execution + CAS + Action Cache endpoints should return both
// CacheCapabilities and ExecutionCapabilities.
// * Execution only endpoints should return ExecutionCapabilities.
// * CAS + Action Cache only endpoints should return CacheCapabilities.
//
// There are no method-specific errors.
rpc GetCapabilities(GetCapabilitiesRequest) returns (ServerCapabilities) {
option (google.api.http) = {
get: "/v2/{instance_name=**}/capabilities"
};
}
}
// An `Action` captures all the information about an execution which is required
// to reproduce it.
//
// `Action`s are the core component of the [Execution] service. A single
// `Action` represents a repeatable action that can be performed by the
// execution service. `Action`s can be succinctly identified by the digest of
// their wire format encoding and, once an `Action` has been executed, will be
// cached in the action cache. Future requests can then use the cached result
// rather than needing to run afresh.
//
// When a server completes execution of an
// [Action][build.bazel.remote.execution.v2.Action], it MAY choose to
// cache the [result][build.bazel.remote.execution.v2.ActionResult] in
// the [ActionCache][build.bazel.remote.execution.v2.ActionCache] unless
// `do_not_cache` is `true`. Clients SHOULD expect the server to do so. By
// default, future calls to
// [Execute][build.bazel.remote.execution.v2.Execution.Execute] the same
// `Action` will also serve their results from the cache. Clients must take care
// to understand the caching behaviour. Ideally, all `Action`s will be
// reproducible so that serving a result from cache is always desirable and
// correct.
message Action {
// The digest of the [Command][build.bazel.remote.execution.v2.Command]
// to run, which MUST be present in the
// [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage].
Digest command_digest = 1;
// The digest of the root
// [Directory][build.bazel.remote.execution.v2.Directory] for the input
// files. The files in the directory tree are available in the correct
// location on the build machine before the command is executed. The root
// directory, as well as every subdirectory and content blob referred to, MUST
// be in the
// [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage].
Digest input_root_digest = 2;
reserved 3 to 5; // Used for fields moved to [Command][build.bazel.remote.execution.v2.Command].
// A timeout after which the execution should be killed. If the timeout is
// absent, then the client is specifying that the execution should continue
// as long as the server will let it. The server SHOULD impose a timeout if
// the client does not specify one, however, if the client does specify a
// timeout that is longer than the server's maximum timeout, the server MUST
// reject the request.
//
// The timeout is only intended to cover the "execution" of the specified
// action and not time in queue nor any overheads before or after execution
// such as marshalling inputs/outputs. The server SHOULD avoid including time
// spent the client doesn't have control over, and MAY extend or reduce the
// timeout to account for delays or speedups that occur during execution
// itself (e.g., lazily loading data from the Content Addressable Storage,
// live migration of virtual machines, emulation overhead).
//
// The timeout is a part of the
// [Action][build.bazel.remote.execution.v2.Action] message, and
// therefore two `Actions` with different timeouts are different, even if they
// are otherwise identical. This is because, if they were not, running an
// `Action` with a lower timeout than is required might result in a cache hit
// from an execution run with a longer timeout, hiding the fact that the
// timeout is too short. By encoding it directly in the `Action`, a lower
// timeout will result in a cache miss and the execution timeout will fail
// immediately, rather than whenever the cache entry gets evicted.
google.protobuf.Duration timeout = 6;
// If true, then the `Action`'s result cannot be cached, and in-flight
// requests for the same `Action` may not be merged.
bool do_not_cache = 7;
reserved 8; // Used for field moved to [Command][build.bazel.remote.execution.v2.Command].
// An optional additional salt value used to place this `Action` into a
// separate cache namespace from other instances having the same field
// contents. This salt typically comes from operational configuration
// specific to sources such as repo and service configuration,
// and allows disowning an entire set of ActionResults that might have been
// poisoned by buggy software or tool failures.
bytes salt = 9;
// The optional platform requirements for the execution environment. The
// server MAY choose to execute the action on any worker satisfying the
// requirements, so the client SHOULD ensure that running the action on any
// such worker will have the same result. A detailed lexicon for this can be
// found in the accompanying platform.md.
// New in version 2.2: clients SHOULD set these platform properties as well
// as those in the [Command][build.bazel.remote.execution.v2.Command]. Servers
// SHOULD prefer those set here.
Platform platform = 10;
}
// A `Command` is the actual command executed by a worker running an
// [Action][build.bazel.remote.execution.v2.Action] and specifications of its
// environment.
//
// Except as otherwise required, the environment (such as which system
// libraries or binaries are available, and what filesystems are mounted where)
// is defined by and specific to the implementation of the remote execution API.
message Command {
// An `EnvironmentVariable` is one variable to set in the running program's
// environment.
message EnvironmentVariable {
// The variable name.
string name = 1;
// The variable value.
string value = 2;
}
// The arguments to the command.
//
// The first argument specifies the command to run, which may be either an
// absolute path, a path relative to the working directory, or an unqualified
// path (without path separators) which will be resolved using the operating
// system's equivalent of the PATH environment variable. Path separators
// native to the operating system running on the worker SHOULD be used. If the
// `environment_variables` list contains an entry for the PATH environment
// variable, it SHOULD be respected. If not, the resolution process is
// implementation-defined.
//
// Changed in v2.3. v2.2 and older require that no PATH lookups are performed,
// and that relative paths are resolved relative to the input root. This
// behavior can, however, not be relied upon, as most implementations already
// followed the rules described above.
repeated string arguments = 1;
// The environment variables to set when running the program. The worker may
// provide its own default environment variables; these defaults can be
// overridden using this field. Additional variables can also be specified.
//
// In order to ensure that equivalent
// [Command][build.bazel.remote.execution.v2.Command]s always hash to the same
// value, the environment variables MUST be lexicographically sorted by name.
// Sorting of strings is done by code point, equivalently, by the UTF-8 bytes.
repeated EnvironmentVariable environment_variables = 2;
// A list of the output files that the client expects to retrieve from the
// action. Only the listed files, as well as directories listed in
// `output_directories`, will be returned to the client as output.
// Other files or directories that may be created during command execution
// are discarded.
//
// The paths are relative to the working directory of the action execution.
// The paths are specified using a single forward slash (`/`) as a path
// separator, even if the execution platform natively uses a different
// separator. The path MUST NOT include a trailing slash, nor a leading slash,
// being a relative path.
//
// In order to ensure consistent hashing of the same Action, the output paths
// MUST be sorted lexicographically by code point (or, equivalently, by UTF-8
// bytes).
//
// An output file cannot be duplicated, be a parent of another output file, or
// have the same path as any of the listed output directories.
//
// Directories leading up to the output files are created by the worker prior
// to execution, even if they are not explicitly part of the input root.
//
// DEPRECATED since v2.1: Use `output_paths` instead.
repeated string output_files = 3 [ deprecated = true ];
// A list of the output directories that the client expects to retrieve from
// the action. Only the listed directories will be returned (an entire
// directory structure will be returned as a
// [Tree][build.bazel.remote.execution.v2.Tree] message digest, see
// [OutputDirectory][build.bazel.remote.execution.v2.OutputDirectory]), as
// well as files listed in `output_files`. Other files or directories that
// may be created during command execution are discarded.
//
// The paths are relative to the working directory of the action execution.
// The paths are specified using a single forward slash (`/`) as a path
// separator, even if the execution platform natively uses a different
// separator. The path MUST NOT include a trailing slash, nor a leading slash,
// being a relative path. The special value of empty string is allowed,
// although not recommended, and can be used to capture the entire working
// directory tree, including inputs.
//
// In order to ensure consistent hashing of the same Action, the output paths
// MUST be sorted lexicographically by code point (or, equivalently, by UTF-8
// bytes).
//
// An output directory cannot be duplicated or have the same path as any of
// the listed output files. An output directory is allowed to be a parent of
// another output directory.
//
// Directories leading up to the output directories (but not the output
// directories themselves) are created by the worker prior to execution, even
// if they are not explicitly part of the input root.
//
// DEPRECATED since 2.1: Use `output_paths` instead.
repeated string output_directories = 4 [ deprecated = true ];
// A list of the output paths that the client expects to retrieve from the
// action. Only the listed paths will be returned to the client as output.
// The type of the output (file or directory) is not specified, and will be
// determined by the server after action execution. If the resulting path is
// a file, it will be returned in an
// [OutputFile][build.bazel.remote.execution.v2.OutputFile] typed field.
// If the path is a directory, the entire directory structure will be returned
// as a [Tree][build.bazel.remote.execution.v2.Tree] message digest, see
// [OutputDirectory][build.bazel.remote.execution.v2.OutputDirectory]
// Other files or directories that may be created during command execution
// are discarded.
//
// The paths are relative to the working directory of the action execution.
// The paths are specified using a single forward slash (`/`) as a path
// separator, even if the execution platform natively uses a different
// separator. The path MUST NOT include a trailing slash, nor a leading slash,
// being a relative path.
//
// In order to ensure consistent hashing of the same Action, the output paths
// MUST be deduplicated and sorted lexicographically by code point (or,
// equivalently, by UTF-8 bytes).
//
// Directories leading up to the output paths are created by the worker prior
// to execution, even if they are not explicitly part of the input root.
//
// New in v2.1: this field supersedes the DEPRECATED `output_files` and
// `output_directories` fields. If `output_paths` is used, `output_files` and
// `output_directories` will be ignored!
repeated string output_paths = 7;
// The platform requirements for the execution environment. The server MAY
// choose to execute the action on any worker satisfying the requirements, so
// the client SHOULD ensure that running the action on any such worker will
// have the same result. A detailed lexicon for this can be found in the
// accompanying platform.md.
// DEPRECATED as of v2.2: platform properties are now specified directly in
// the action. See documentation note in the
// [Action][build.bazel.remote.execution.v2.Action] for migration.
Platform platform = 5 [ deprecated = true ];
// The working directory, relative to the input root, for the command to run
// in. It must be a directory which exists in the input tree. If it is left
// empty, then the action is run in the input root.
string working_directory = 6;
// A list of keys for node properties the client expects to retrieve for
// output files and directories. Keys are either names of string-based
// [NodeProperty][build.bazel.remote.execution.v2.NodeProperty] or
// names of fields in [NodeProperties][build.bazel.remote.execution.v2.NodeProperties].
// In order to ensure that equivalent `Action`s always hash to the same
// value, the node properties MUST be lexicographically sorted by name.
// Sorting of strings is done by code point, equivalently, by the UTF-8 bytes.
//
// The interpretation of string-based properties is server-dependent. If a
// property is not recognized by the server, the server will return an
// `INVALID_ARGUMENT`.
repeated string output_node_properties = 8;
enum OutputDirectoryFormat {
// The client is only interested in receiving output directories in
// the form of a single Tree object, using the `tree_digest` field.
TREE_ONLY = 0;
// The client is only interested in receiving output directories in
// the form of a hierarchy of separately stored Directory objects,
// using the `root_directory_digest` field.
DIRECTORY_ONLY = 1;
// The client is interested in receiving output directories both in
// the form of a single Tree object and a hierarchy of separately
// stored Directory objects, using both the `tree_digest` and
// `root_directory_digest` fields.
TREE_AND_DIRECTORY = 2;
}
// The format that the worker should use to store the contents of
// output directories.
//
// In case this field is set to a value that is not supported by the
// worker, the worker SHOULD interpret this field as TREE_ONLY. The
// worker MAY store output directories in formats that are a superset
// of what was requested (e.g., interpreting DIRECTORY_ONLY as
// TREE_AND_DIRECTORY).
OutputDirectoryFormat output_directory_format = 9;
}
// A `Platform` is a set of requirements, such as hardware, operating system, or
// compiler toolchain, for an
// [Action][build.bazel.remote.execution.v2.Action]'s execution
// environment. A `Platform` is represented as a series of key-value pairs
// representing the properties that are required of the platform.
message Platform {
// A single property for the environment. The server is responsible for
// specifying the property `name`s that it accepts. If an unknown `name` is
// provided in the requirements for an
// [Action][build.bazel.remote.execution.v2.Action], the server SHOULD
// reject the execution request. If permitted by the server, the same `name`
// may occur multiple times.
//
// The server is also responsible for specifying the interpretation of
// property `value`s. For instance, a property describing how much RAM must be
// available may be interpreted as allowing a worker with 16GB to fulfill a
// request for 8GB, while a property describing the OS environment on which
// the action must be performed may require an exact match with the worker's
// OS.
//
// The server MAY use the `value` of one or more properties to determine how
// it sets up the execution environment, such as by making specific system
// files available to the worker.
//
// Both names and values are typically case-sensitive. Note that the platform
// is implicitly part of the action digest, so even tiny changes in the names
// or values (like changing case) may result in different action cache
// entries.
message Property {
// The property name.
string name = 1;
// The property value.
string value = 2;
}
// The properties that make up this platform. In order to ensure that
// equivalent `Platform`s always hash to the same value, the properties MUST
// be lexicographically sorted by name, and then by value. Sorting of strings
// is done by code point, equivalently, by the UTF-8 bytes.
repeated Property properties = 1;
}
// A `Directory` represents a directory node in a file tree, containing zero or
// more children [FileNodes][build.bazel.remote.execution.v2.FileNode],
// [DirectoryNodes][build.bazel.remote.execution.v2.DirectoryNode] and
// [SymlinkNodes][build.bazel.remote.execution.v2.SymlinkNode].
// Each `Node` contains its name in the directory, either the digest of its
// content (either a file blob or a `Directory` proto) or a symlink target, as
// well as possibly some metadata about the file or directory.
//
// In order to ensure that two equivalent directory trees hash to the same
// value, the following restrictions MUST be obeyed when constructing a
// a `Directory`:
//
// * Every child in the directory must have a path of exactly one segment.
// Multiple levels of directory hierarchy may not be collapsed.
// * Each child in the directory must have a unique path segment (file name).
// Note that while the API itself is case-sensitive, the environment where
// the Action is executed may or may not be case-sensitive. That is, it is
// legal to call the API with a Directory that has both "Foo" and "foo" as
// children, but the Action may be rejected by the remote system upon
// execution.
// * The files, directories and symlinks in the directory must each be sorted
// in lexicographical order by path. The path strings must be sorted by code
// point, equivalently, by UTF-8 bytes.
// * The [NodeProperties][build.bazel.remote.execution.v2.NodeProperty] of files,
// directories, and symlinks must be sorted in lexicographical order by
// property name.
//
// A `Directory` that obeys the restrictions is said to be in canonical form.
//
// As an example, the following could be used for a file named `bar` and a
// directory named `foo` with an executable file named `baz` (hashes shortened
// for readability):
//
// ```json
// // (Directory proto)
// {
// files: [
// {
// name: "bar",
// digest: {
// hash: "4a73bc9d03...",
// size: 65534
// },
// node_properties: [
// {
// "name": "MTime",
// "value": "2017-01-15T01:30:15.01Z"
// }
// ]
// }
// ],
// directories: [
// {
// name: "foo",
// digest: {
// hash: "4cf2eda940...",
// size: 43
// }
// }
// ]
// }
//
// // (Directory proto with hash "4cf2eda940..." and size 43)
// {
// files: [
// {
// name: "baz",
// digest: {
// hash: "b2c941073e...",
// size: 1294,
// },
// is_executable: true
// }
// ]
// }
// ```
message Directory {
// The files in the directory.
repeated FileNode files = 1;
// The subdirectories in the directory.
repeated DirectoryNode directories = 2;
// The symlinks in the directory.
repeated SymlinkNode symlinks = 3;
// The node properties of the Directory.
reserved 4;
NodeProperties node_properties = 5;
}
// A single property for [FileNodes][build.bazel.remote.execution.v2.FileNode],
// [DirectoryNodes][build.bazel.remote.execution.v2.DirectoryNode], and
// [SymlinkNodes][build.bazel.remote.execution.v2.SymlinkNode]. The server is
// responsible for specifying the property `name`s that it accepts. If
// permitted by the server, the same `name` may occur multiple times.
message NodeProperty {
// The property name.
string name = 1;
// The property value.
string value = 2;
}
// Node properties for [FileNodes][build.bazel.remote.execution.v2.FileNode],
// [DirectoryNodes][build.bazel.remote.execution.v2.DirectoryNode], and
// [SymlinkNodes][build.bazel.remote.execution.v2.SymlinkNode]. The server is
// responsible for specifying the properties that it accepts.
//
message NodeProperties {
// A list of string-based
// [NodeProperties][build.bazel.remote.execution.v2.NodeProperty].
repeated NodeProperty properties = 1;
// The file's last modification timestamp.
google.protobuf.Timestamp mtime = 2;
// The UNIX file mode, e.g., 0755.
google.protobuf.UInt32Value unix_mode = 3;
}
// A `FileNode` represents a single file and associated metadata.
message FileNode {
// The name of the file.
string name = 1;
// The digest of the file's content.
Digest digest = 2;
reserved 3; // Reserved to ensure wire-compatibility with `OutputFile`.
// True if file is executable, false otherwise.
bool is_executable = 4;
// The node properties of the FileNode.
reserved 5;
NodeProperties node_properties = 6;
}
// A `DirectoryNode` represents a child of a
// [Directory][build.bazel.remote.execution.v2.Directory] which is itself
// a `Directory` and its associated metadata.
message DirectoryNode {
// The name of the directory.
string name = 1;
// The digest of the
// [Directory][build.bazel.remote.execution.v2.Directory] object
// represented. See [Digest][build.bazel.remote.execution.v2.Digest]
// for information about how to take the digest of a proto message.
Digest digest = 2;
}
// A `SymlinkNode` represents a symbolic link.
message SymlinkNode {
// The name of the symlink.
string name = 1;
// The target path of the symlink. The path separator is a forward slash `/`.
// The target path can be relative to the parent directory of the symlink or
// it can be an absolute path starting with `/`. Support for absolute paths
// can be checked using the [Capabilities][build.bazel.remote.execution.v2.Capabilities]
// API. `..` components are allowed anywhere in the target path as logical
// canonicalization may lead to different behavior in the presence of
// directory symlinks (e.g. `foo/../bar` may not be the same as `bar`).
// To reduce potential cache misses, canonicalization is still recommended
// where this is possible without impacting correctness.
string target = 2;
// The node properties of the SymlinkNode.
reserved 3;
NodeProperties node_properties = 4;
}
// A content digest. A digest for a given blob consists of the size of the blob
// and its hash. The hash algorithm to use is defined by the server.
//
// The size is considered to be an integral part of the digest and cannot be
// separated. That is, even if the `hash` field is correctly specified but
// `size_bytes` is not, the server MUST reject the request.
//
// The reason for including the size in the digest is as follows: in a great
// many cases, the server needs to know the size of the blob it is about to work
// with prior to starting an operation with it, such as flattening Merkle tree
// structures or streaming it to a worker. Technically, the server could
// implement a separate metadata store, but this results in a significantly more
// complicated implementation as opposed to having the client specify the size
// up-front (or storing the size along with the digest in every message where
// digests are embedded). This does mean that the API leaks some implementation
// details of (what we consider to be) a reasonable server implementation, but
// we consider this to be a worthwhile tradeoff.
//
// When a `Digest` is used to refer to a proto message, it always refers to the
// message in binary encoded form. To ensure consistent hashing, clients and
// servers MUST ensure that they serialize messages according to the following
// rules, even if there are alternate valid encodings for the same message:
//
// * Fields are serialized in tag order.
// * There are no unknown fields.
// * There are no duplicate fields.
// * Fields are serialized according to the default semantics for their type.
//
// Most protocol buffer implementations will always follow these rules when
// serializing, but care should be taken to avoid shortcuts. For instance,
// concatenating two messages to merge them may produce duplicate fields.
message Digest {
// The hash, represented as a lowercase hexadecimal string, padded with
// leading zeroes up to the hash function length.
string hash = 1;
// The size of the blob, in bytes.
int64 size_bytes = 2;
}
// ExecutedActionMetadata contains details about a completed execution.
message ExecutedActionMetadata {
// The name of the worker which ran the execution.
string worker = 1;
// When was the action added to the queue.
google.protobuf.Timestamp queued_timestamp = 2;
// When the worker received the action.