Class: Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Action
- Inherits:
-
Object
- Object
- Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Action
- 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
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.
-
#platform ⇒ Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Platform
A
Platform
is a set of requirements, such as hardware, operating system, or compiler toolchain, for an Action's execution environment. -
#salt ⇒ String
An optional additional salt value used to place this
Action
into a separate cache namespace from other instances having the same field contents. -
#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.
139 140 141 |
# File 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 139 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 'lib/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 'lib/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 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 102 def input_root_digest @input_root_digest end |
#platform ⇒ Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Platform
A Platform
is a set of requirements, such as hardware, operating system, or
compiler toolchain, for an Action's execution environment. A Platform
is
represented as a series of key-value pairs representing the properties that
are required of the platform.
Corresponds to the JSON property platform
110 111 112 |
# File 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 110 def platform @platform end |
#salt ⇒ String
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.
Corresponds to the JSON property salt
NOTE: Values are automatically base64 encoded/decoded in the client library.
120 121 122 |
# File 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 120 def salt @salt 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
137 138 139 |
# File 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 137 def timeout @timeout end |
Instance Method Details
#update!(**args) ⇒ Object
Update properties of this object
144 145 146 147 148 149 150 151 |
# File 'lib/google/apis/remotebuildexecution_v2/classes.rb', line 144 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) @platform = args[:platform] if args.key?(:platform) @salt = args[:salt] if args.key?(:salt) @timeout = args[:timeout] if args.key?(:timeout) end |