generated/google/apis/remotebuildexecution_v2/classes.rb in google-api-client-0.27.3 vs generated/google/apis/remotebuildexecution_v2/classes.rb in google-api-client-0.28.0

- old
+ new

@@ -61,15 +61,15 @@ # 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. + # 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` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -98,15 +98,15 @@ # 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. + # 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` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -303,15 +303,15 @@ # 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. + # 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 `stderrDigest` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -345,15 +345,15 @@ # 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. + # 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 `stdoutDigest` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -456,15 +456,15 @@ # 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. + # 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 `digest` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -572,15 +572,15 @@ # 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. + # 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 `digest` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -638,15 +638,15 @@ # 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. + # 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 `digest` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -772,54 +772,61 @@ attr_accessor :arguments # 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`s always hash to the same + # In order to ensure that equivalent + # Commands 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. # Corresponds to the JSON property `environmentVariables` # @return [Array<Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2CommandEnvironmentVariable>] attr_accessor :environment_variables # A list of the output directories that the client expects to retrieve from - # the action. Only the contents of the indicated directories (recursively - # including the contents of their subdirectories) will be - # returned, as well as files listed in `output_files`. Other files that may - # be created during command execution are discarded. + # the action. Only the listed directories will be returned (an entire + # directory structure will be returned as a + # Tree message digest, see + # 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, be a parent of another output - # directory, be a parent of a listed output file, or have the same path as - # any of the listed output files. + # An output directory cannot be duplicated or have the same path as any of + # the listed output files. + # 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. # Corresponds to the JSON property `outputDirectories` # @return [Array<String>] attr_accessor :output_directories # 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 that may be created during command execution are discarded. + # 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, be - # a child of a listed output directory, or have the same path as any of the - # listed output directories. + # 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. # Corresponds to the JSON property `outputFiles` # @return [Array<String>] attr_accessor :output_files # A `Platform` is a set of requirements, such as hardware, operating system, or @@ -896,15 +903,15 @@ # 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. + # 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. class BuildBazelRemoteExecutionV2Digest include Google::Apis::Core::Hashable @@ -939,14 +946,14 @@ # 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. + # * 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). - # - The files, directories and symlinks in the directory must each be sorted + # * Each child in the directory must have a unique path segment (file name). + # * 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. # 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 @@ -1040,15 +1047,15 @@ # 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. + # 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 `digest` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -1095,15 +1102,15 @@ # 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. + # 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` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -1163,15 +1170,15 @@ # 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. + # 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` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -1221,10 +1228,16 @@ # Corresponds to the JSON property `cachedResult` # @return [Boolean] attr_accessor :cached_result alias_method :cached_result?, :cached_result + # Freeform informational message with details on the execution of the action + # that may be displayed to the user upon failure or when requested explicitly. + # Corresponds to the JSON property `message` + # @return [String] + attr_accessor :message + # An ActionResult represents the result of an # Action being run. # Corresponds to the JSON property `result` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2ActionResult] attr_accessor :result @@ -1288,10 +1301,11 @@ end # Update properties of this object def update!(**args) @cached_result = args[:cached_result] if args.key?(:cached_result) + @message = args[:message] if args.key?(:message) @result = args[:result] if args.key?(:result) @server_logs = args[:server_logs] if args.key?(:server_logs) @status = args[:status] if args.key?(:status) end end @@ -1451,15 +1465,15 @@ # 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. + # 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 `digest` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -1578,15 +1592,15 @@ # 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. + # 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 `digest` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -1643,15 +1657,15 @@ # 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. + # 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 `treeDigest` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -1693,15 +1707,15 @@ # 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. + # 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 `digest` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2Digest] @@ -1880,12 +1894,12 @@ # An optional Metadata to attach to any RPC request to tell the server about an # external context of the request. The server may use this for logging or other # purposes. To use it, the client attaches the header to the call using the # canonical proto serialization: - # name: build.bazel.remote.execution.v2.requestmetadata-bin - # contents: the base64 encoded binary RequestMetadata message. + # * name: `build.bazel.remote.execution.v2.requestmetadata-bin` + # * contents: the base64 encoded binary `RequestMetadata` message. class BuildBazelRemoteExecutionV2RequestMetadata include Google::Apis::Core::Hashable # An identifier that ties multiple requests to the same action. # For example, multiple requests to the CAS, Action Cache, and Execution @@ -1958,26 +1972,26 @@ # Capabilities of the remote cache system. # Corresponds to the JSON property `cacheCapabilities` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2CacheCapabilities] attr_accessor :cache_capabilities - # Earliest RE API version supported, including deprecated versions. + # The full version of a given tool. # Corresponds to the JSON property `deprecatedApiVersion` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelSemverSemVer] attr_accessor :deprecated_api_version # Capabilities of the remote execution system. # Corresponds to the JSON property `executionCapabilities` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelRemoteExecutionV2ExecutionCapabilities] attr_accessor :execution_capabilities - # Latest RE API version supported. + # The full version of a given tool. # Corresponds to the JSON property `highApiVersion` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelSemverSemVer] attr_accessor :high_api_version - # Earliest non-deprecated RE API version supported. + # The full version of a given tool. # Corresponds to the JSON property `lowApiVersion` # @return [Google::Apis::RemotebuildexecutionV2::BuildBazelSemverSemVer] attr_accessor :low_api_version def initialize(**args) @@ -2071,14 +2085,14 @@ # 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. + # * 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). - # - The files, directories and symlinks in the directory must each be sorted + # * Each child in the directory must have a unique path segment (file name). + # * 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. # 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 @@ -2146,30 +2160,32 @@ # Update properties of this object def update!(**args) end end - # + # The full version of a given tool. class BuildBazelSemverSemVer include Google::Apis::Core::Hashable - # + # The major version, e.g 10 for 10.2.3. # Corresponds to the JSON property `major` # @return [Fixnum] attr_accessor :major - # + # The minor version, e.g. 2 for 10.2.3. # Corresponds to the JSON property `minor` # @return [Fixnum] attr_accessor :minor - # + # The patch version, e.g 3 for 10.2.3. # Corresponds to the JSON property `patch` # @return [Fixnum] attr_accessor :patch - # + # The pre-release version. Either this field or major/minor/patch fields + # must be filled. They are mutually exclusive. Pre-release versions are + # assumed to be earlier than any released versions. # Corresponds to the JSON property `prerelease` # @return [String] attr_accessor :prerelease def initialize(**args) @@ -2450,10 +2466,16 @@ # The location is a GCP region. Currently only `us-central1` is supported. # Corresponds to the JSON property `location` # @return [String] attr_accessor :location + # Output only. Whether stack driver logging is enabled for the instance. + # Corresponds to the JSON property `loggingEnabled` + # @return [Boolean] + attr_accessor :logging_enabled + alias_method :logging_enabled?, :logging_enabled + # Output only. Instance resource name formatted as: # `projects/[PROJECT_ID]/instances/[INSTANCE_ID]`. # Name should not be populated when creating an instance since it is provided # in the `instance_id` field. # Corresponds to the JSON property `name` @@ -2470,10 +2492,11 @@ end # Update properties of this object def update!(**args) @location = args[:location] if args.key?(:location) + @logging_enabled = args[:logging_enabled] if args.key?(:logging_enabled) @name = args[:name] if args.key?(:name) @state = args[:state] if args.key?(:state) end end @@ -2616,12 +2639,14 @@ # See [CPU Platforms](https://cloud.google.com/compute/docs/cpu-platforms). # Corresponds to the JSON property `minCpuPlatform` # @return [String] attr_accessor :min_cpu_platform - # Output only. `reserved=true` means the worker is reserved and won't be - # preempted. + # Determines whether the worker is reserved (and therefore won't be + # preempted). + # See [Preemptible VMs](https://cloud.google.com/preemptible-vms/) for more + # details. # Corresponds to the JSON property `reserved` # @return [Boolean] attr_accessor :reserved alias_method :reserved?, :reserved @@ -3851,10 +3876,20 @@ # `status` has a code of OK (otherwise it may simply be unset). # Corresponds to the JSON property `exitCode` # @return [Fixnum] attr_accessor :exit_code + # Implementation-dependent metadata about the task. Both servers and bots + # may define messages which can be encoded here; bots are free to provide + # metadata in multiple formats, and servers are free to choose one or more + # of the values to process and ignore others. In particular, it is *not* + # considered an error for the bot to provide the server with a field that it + # doesn't know about. + # Corresponds to the JSON property `metadata` + # @return [Array<Hash<String,Object>>] + attr_accessor :metadata + # The CommandTask and CommandResult messages assume the existence of a service # that can serve blobs of content, identified by a hash and size known as a # "digest." The method by which these blobs may be retrieved is not specified # here, but a model implementation is in the Remote Execution API's # "ContentAddressibleStorage" interface. @@ -3869,20 +3904,10 @@ # uploading/downloading files). # Corresponds to the JSON property `overhead` # @return [String] attr_accessor :overhead - # Implementation-dependent statistics about the task. Both servers and bots - # may define messages which can be encoded here; bots are free to provide - # statistics in multiple formats, and servers are free to choose one or more - # of the values to process and ignore others. In particular, it is *not* - # considered an error for the bot to provide the server with a field that it - # doesn't know about. - # Corresponds to the JSON property `statistics` - # @return [Array<Hash<String,Object>>] - attr_accessor :statistics - # The `Status` type defines a logical error model that is suitable for different # programming environments, including REST APIs and RPC APIs. It is used by # [gRPC](https://github.com/grpc). The error model is designed to be: # - Simple to use and understand for most users # - Flexible enough to meet unexpected needs @@ -3930,12 +3955,12 @@ # Update properties of this object def update!(**args) @duration = args[:duration] if args.key?(:duration) @exit_code = args[:exit_code] if args.key?(:exit_code) + @metadata = args[:metadata] if args.key?(:metadata) @outputs = args[:outputs] if args.key?(:outputs) @overhead = args[:overhead] if args.key?(:overhead) - @statistics = args[:statistics] if args.key?(:statistics) @status = args[:status] if args.key?(:status) end end # Describes a shell-style task to execute, suitable for providing as the Bots