Class: Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Action
- Inherits:
-
Object
- Object
- Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Action
- Includes:
- Core::Hashable, Core::JsonObjectSupport
- Defined in:
- generated/google/apis/remotebuildexecution_v2/classes.rb,
generated/google/apis/remotebuildexecution_v2/representations.rb,
generated/google/apis/remotebuildexecution_v2/representations.rb
Overview
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, it MAY choose to cache the result in the ActionCache unless
do_not_cache
is true
. Clients SHOULD expect the server to do so. By default,
future calls to 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.
Instance Attribute Summary collapse
-
#command_digest ⇒ Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest
A content digest.
-
#do_not_cache ⇒ Boolean
(also: #do_not_cache?)
If true, then the
Action
's result cannot be cached, and in-flight requests for the sameAction
may not be merged. -
#input_root_digest ⇒ Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest
A content digest.
-
#output_node_properties ⇒ Array<String>
List of required supported NodeProperty keys.
-
#timeout ⇒ String
A timeout after which the execution should be killed.
Instance Method Summary collapse
-
#initialize(**args) ⇒ BuildBazelRemoteExecutionV2Action
constructor
A new instance of BuildBazelRemoteExecutionV2Action.
-
#update!(**args) ⇒ Object
Update properties of this object.
Constructor Details
#initialize(**args) ⇒ BuildBazelRemoteExecutionV2Action
Returns a new instance of BuildBazelRemoteExecutionV2Action.
131 132 133 |
# File 'generated/google/apis/remotebuildexecution_v2/classes.rb', line 131 def initialize(**args) update!(**args) end |
Instance Attribute Details
#command_digest ⇒ Google::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 commandDigest
67 68 69 |
# File 'generated/google/apis/remotebuildexecution_v2/classes.rb', line 67 def command_digest @command_digest end |
#do_not_cache ⇒ Boolean Also known as: do_not_cache?
If true, then the Action
's result cannot be cached, and in-flight requests
for the same Action
may not be merged.
Corresponds to the JSON property doNotCache
73 74 75 |
# File 'generated/google/apis/remotebuildexecution_v2/classes.rb', line 73 def do_not_cache @do_not_cache end |
#input_root_digest ⇒ Google::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 inputRootDigest
102 103 104 |
# File 'generated/google/apis/remotebuildexecution_v2/classes.rb', line 102 def input_root_digest @input_root_digest end |
#output_node_properties ⇒ Array<String>
List of required supported NodeProperty keys. In order to ensure that
equivalent Action
s always hash to the same value, the supported 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
these properties is server-dependent. If a property is not recognized by the
server, the server will return an INVALID_ARGUMENT
error.
Corresponds to the JSON property outputNodeProperties
112 113 114 |
# File 'generated/google/apis/remotebuildexecution_v2/classes.rb', line 112 def output_node_properties @output_node_properties end |
#timeout ⇒ String
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 a part of the 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.
Corresponds to the JSON property timeout
129 130 131 |
# File 'generated/google/apis/remotebuildexecution_v2/classes.rb', line 129 def timeout @timeout end |
Instance Method Details
#update!(**args) ⇒ Object
Update properties of this object
136 137 138 139 140 141 142 |
# File 'generated/google/apis/remotebuildexecution_v2/classes.rb', line 136 def update!(**args) @command_digest = args[:command_digest] if args.key?(:command_digest) @do_not_cache = args[:do_not_cache] if args.key?(:do_not_cache) @input_root_digest = args[:input_root_digest] if args.key?(:input_root_digest) @output_node_properties = args[:output_node_properties] if args.key?(:output_node_properties) @timeout = args[:timeout] if args.key?(:timeout) end |