google-api-client 0.27.3 → 0.28.0

data/generated/google/apis/remotebuildexecution_v2/classes.rb

@@ -63,11 +63,11 @@ module Google
         # 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.
@@ -100,11 +100,11 @@ module Google
         # 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.
@@ -305,11 +305,11 @@ module Google
         # 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.
@@ -347,11 +347,11 @@ module Google
         # 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.
@@ -458,11 +458,11 @@ module Google
         # 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.
@@ -574,11 +574,11 @@ module Google
         # 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.
@@ -640,11 +640,11 @@ module Google
         # 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.
@@ -774,7 +774,8 @@ module Google
         # 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`
@@ -782,10 +783,12 @@ module Google
         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
@@ -796,9 +799,11 @@ module Google
         # 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
@@ -806,7 +811,8 @@ module Google
         # 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
@@ -815,9 +821,10 @@ module Google
         # 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
@@ -898,11 +905,11 @@ module Google
       # 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.
@@ -941,10 +948,10 @@ module Google
       # 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.
@@ -1042,11 +1049,11 @@ module Google
         # 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.
@@ -1097,11 +1104,11 @@ module Google
         # 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.
@@ -1165,11 +1172,11 @@ module Google
         # 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.
@@ -1223,6 +1230,12 @@ module Google
         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`
@@ -1290,6 +1303,7 @@ module Google
         # 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)
@@ -1453,11 +1467,11 @@ module Google
         # 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.
@@ -1580,11 +1594,11 @@ module Google
         # 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.
@@ -1645,11 +1659,11 @@ module Google
         # 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.
@@ -1695,11 +1709,11 @@ module Google
         # 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.
@@ -1882,8 +1896,8 @@ module Google
       # 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
       
@@ -1960,7 +1974,7 @@ module Google
         # @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
@@ -1970,12 +1984,12 @@ module Google
         # @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
@@ -2073,10 +2087,10 @@ module Google
         # 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.
@@ -2148,26 +2162,28 @@ module Google
         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
@@ -2452,6 +2468,12 @@ module Google
         # @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
@@ -2472,6 +2494,7 @@ module Google
         # 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
@@ -2618,8 +2641,10 @@ module Google
         # @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
@@ -3853,6 +3878,16 @@ module Google
         # @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
@@ -3871,16 +3906,6 @@ module Google
         # @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:
@@ -3932,9 +3957,9 @@ module Google
         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