Class: Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2ExecuteRequest

Inherits:
Object
  • Object
show all
Includes:
Core::Hashable, Core::JsonObjectSupport
Defined in:
lib/google/apis/remotebuildexecution_v2/classes.rb,
lib/google/apis/remotebuildexecution_v2/representations.rb,
lib/google/apis/remotebuildexecution_v2/representations.rb

Overview

A request message for Execution.Execute.

Instance Attribute Summary collapse

Instance Method Summary collapse

Constructor Details

#initialize(**args) ⇒ BuildBazelRemoteExecutionV2ExecuteRequest

Returns a new instance of BuildBazelRemoteExecutionV2ExecuteRequest.



1110
1111
1112
# File 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 1110

def initialize(**args)
   update!(**args)
end

Instance Attribute Details

#action_digestGoogle::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest

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. Corresponds to the JSON property actionDigest



1081
1082
1083
# File 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 1081

def action_digest
  @action_digest
end

#execution_policyGoogle::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2ExecutionPolicy

An ExecutionPolicy can be used to control the scheduling of the action. Corresponds to the JSON property executionPolicy



1086
1087
1088
# File 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 1086

def execution_policy
  @execution_policy
end

#results_cache_policyGoogle::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2ResultsCachePolicy

A ResultsCachePolicy is used for fine-grained control over how action outputs are stored in the CAS and Action Cache. Corresponds to the JSON property resultsCachePolicy



1092
1093
1094
# File 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 1092

def results_cache_policy
  @results_cache_policy
end

#skip_cache_lookupBoolean Also known as: skip_cache_lookup?

If true, the action will be executed even if its result is already present in the ActionCache. The execution is still allowed to be merged with other in- flight executions of the same action, however - semantically, the service MUST only guarantee that the results of an execution with this field set were not visible before the corresponding execution request was sent. Note that actions from execution requests setting this field set are still eligible to be entered into the action cache upon completion, and services SHOULD overwrite any existing entries that may exist. This allows skip_cache_lookup requests to be used as a mechanism for replacing action cache entries that reference outputs no longer available or that are poisoned in any way. If false, the result may be served from the action cache. Corresponds to the JSON property skipCacheLookup

Returns:

  • (Boolean)


1107
1108
1109
# File 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 1107

def skip_cache_lookup
  @skip_cache_lookup
end

Instance Method Details

#update!(**args) ⇒ Object

Update properties of this object



1115
1116
1117
1118
1119
1120
# File 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 1115

def update!(**args)
  @action_digest = args[:action_digest] if args.key?(:action_digest)
  @execution_policy = args[:execution_policy] if args.key?(:execution_policy)
  @results_cache_policy = args[:results_cache_policy] if args.key?(:results_cache_policy)
  @skip_cache_lookup = args[:skip_cache_lookup] if args.key?(:skip_cache_lookup)
end