chiu/google-api-ruby-client
1
0 Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Autogenerated update (2019-01-18)

Browse Source 
Delete:
- monitoring_v1

Update:
- ml_v1
- remotebuildexecution_v1
- remotebuildexecution_v1alpha
- remotebuildexecution_v2
This commit is contained in:
Google APIs committed 2019-01-18 00:37:00 +00:00
1 parent cdb6c27105
commit aaa8267814
20 files changed
+503 -1229
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

generated/google/apis/remotebuildexecution_v2/classes.rb
+141 -116
View File
@@ -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