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

Autogenerated update (2019-06-07) 

Update:
- appengine_v1
- appengine_v1alpha
- appengine_v1beta
- cloudtasks_v2beta2
- container_v1beta1
- genomics_v1
- genomics_v1alpha2
- genomics_v2alpha1
- monitoring_v3
- remotebuildexecution_v1
- remotebuildexecution_v1alpha
- remotebuildexecution_v2
- runtimeconfig_v1
- runtimeconfig_v1beta1
- serviceconsumermanagement_v1
- servicenetworking_v1
- servicenetworking_v1beta
- serviceusage_v1
- serviceusage_v1beta1
- storage_v1
This commit is contained in:
Google APIs 2019-06-07 00:37:26 +00:00
parent 5b4eab2abf
commit 33aabc9a9c
42 changed files with 202 additions and 1468 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
generated/google/apis/appengine_v1.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://cloud.google.com/appengine/docs/admin-api/
module AppengineV1
VERSION = 'V1'
REVISION = '20190503'
REVISION = '20190531'
# View and manage your applications deployed on Google App Engine
AUTH_APPENGINE_ADMIN = 'https://www.googleapis.com/auth/appengine.admin'

72
generated/google/apis/appengine_v1/classes.rb
View File

@ -1796,38 +1796,10 @@ module Google
# 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 needsOverviewThe Status message contains
# three pieces of data: error code, error message, and error details. The error
# code should be an enum value of google.rpc.Code, but it may accept additional
# error codes if needed. The error message should be a developer-facing English
# message that helps developers understand and resolve the error. If a localized
# user-facing error message is needed, put the localized message in the error
# details or localize it in the client. The optional error details may contain
# arbitrary information about the error. There is a predefined set of error
# detail types in the package google.rpc that can be used for common error
# conditions.Language mappingThe Status message is the logical representation of
# the error model, but it is not necessarily the actual wire format. When the
# Status message is exposed in different client libraries and different wire
# protocols, it can be mapped differently. For example, it will likely be mapped
# to some exceptions in Java, but more likely mapped to some error codes in C.
# Other usesThe error model and the Status message can be used in a variety of
# environments, either with or without APIs, to provide a consistent developer
# experience across different environments.Example uses of this error model
# include:
# Partial errors. If a service needs to return partial errors to the client, it
# may embed the Status in the normal response to indicate the partial errors.
# Workflow errors. A typical workflow has multiple steps. Each step may have a
# Status message for error reporting.
# Batch operations. If a client uses batch request and batch response, the
# Status message should be used directly inside batch response, one for each
# error sub-response.
# Asynchronous operations. If an API call embeds asynchronous operation results
# in its response, the status of those operations should be represented directly
# using the Status message.
# Logging. If some API errors are stored in logs, the message Status could be
# used directly after any stripping needed for security/privacy reasons.
# (https://github.com/grpc). Each Status message contains three pieces of data:
# error code, error message, and error details.You can find out more about this
# error model and how to work with it in the API Design Guide (https://cloud.
# google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::AppengineV1::Status]
attr_accessor :error
@ -2445,38 +2417,10 @@ module Google
# 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 needsOverviewThe Status message contains
# three pieces of data: error code, error message, and error details. The error
# code should be an enum value of google.rpc.Code, but it may accept additional
# error codes if needed. The error message should be a developer-facing English
# message that helps developers understand and resolve the error. If a localized
# user-facing error message is needed, put the localized message in the error
# details or localize it in the client. The optional error details may contain
# arbitrary information about the error. There is a predefined set of error
# detail types in the package google.rpc that can be used for common error
# conditions.Language mappingThe Status message is the logical representation of
# the error model, but it is not necessarily the actual wire format. When the
# Status message is exposed in different client libraries and different wire
# protocols, it can be mapped differently. For example, it will likely be mapped
# to some exceptions in Java, but more likely mapped to some error codes in C.
# Other usesThe error model and the Status message can be used in a variety of
# environments, either with or without APIs, to provide a consistent developer
# experience across different environments.Example uses of this error model
# include:
# Partial errors. If a service needs to return partial errors to the client, it
# may embed the Status in the normal response to indicate the partial errors.
# Workflow errors. A typical workflow has multiple steps. Each step may have a
# Status message for error reporting.
# Batch operations. If a client uses batch request and batch response, the
# Status message should be used directly inside batch response, one for each
# error sub-response.
# Asynchronous operations. If an API call embeds asynchronous operation results
# in its response, the status of those operations should be represented directly
# using the Status message.
# Logging. If some API errors are stored in logs, the message Status could be
# used directly after any stripping needed for security/privacy reasons.
# (https://github.com/grpc). Each Status message contains three pieces of data:
# error code, error message, and error details.You can find out more about this
# error model and how to work with it in the API Design Guide (https://cloud.
# google.com/apis/design/errors).
class Status
include Google::Apis::Core::Hashable

2
generated/google/apis/appengine_v1alpha.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://cloud.google.com/appengine/docs/admin-api/
module AppengineV1alpha
VERSION = 'V1alpha'
REVISION = '20190503'
REVISION = '20190531'
# View and manage your applications deployed on Google App Engine
AUTH_APPENGINE_ADMIN = 'https://www.googleapis.com/auth/appengine.admin'

72
generated/google/apis/appengine_v1alpha/classes.rb
View File

@ -528,38 +528,10 @@ module Google
# 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 needsOverviewThe Status message contains
# three pieces of data: error code, error message, and error details. The error
# code should be an enum value of google.rpc.Code, but it may accept additional
# error codes if needed. The error message should be a developer-facing English
# message that helps developers understand and resolve the error. If a localized
# user-facing error message is needed, put the localized message in the error
# details or localize it in the client. The optional error details may contain
# arbitrary information about the error. There is a predefined set of error
# detail types in the package google.rpc that can be used for common error
# conditions.Language mappingThe Status message is the logical representation of
# the error model, but it is not necessarily the actual wire format. When the
# Status message is exposed in different client libraries and different wire
# protocols, it can be mapped differently. For example, it will likely be mapped
# to some exceptions in Java, but more likely mapped to some error codes in C.
# Other usesThe error model and the Status message can be used in a variety of
# environments, either with or without APIs, to provide a consistent developer
# experience across different environments.Example uses of this error model
# include:
# Partial errors. If a service needs to return partial errors to the client, it
# may embed the Status in the normal response to indicate the partial errors.
# Workflow errors. A typical workflow has multiple steps. Each step may have a
# Status message for error reporting.
# Batch operations. If a client uses batch request and batch response, the
# Status message should be used directly inside batch response, one for each
# error sub-response.
# Asynchronous operations. If an API call embeds asynchronous operation results
# in its response, the status of those operations should be represented directly
# using the Status message.
# Logging. If some API errors are stored in logs, the message Status could be
# used directly after any stripping needed for security/privacy reasons.
# (https://github.com/grpc). Each Status message contains three pieces of data:
# error code, error message, and error details.You can find out more about this
# error model and how to work with it in the API Design Guide (https://cloud.
# google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::AppengineV1alpha::Status]
attr_accessor :error
@ -867,38 +839,10 @@ module Google
# 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 needsOverviewThe Status message contains
# three pieces of data: error code, error message, and error details. The error
# code should be an enum value of google.rpc.Code, but it may accept additional
# error codes if needed. The error message should be a developer-facing English
# message that helps developers understand and resolve the error. If a localized
# user-facing error message is needed, put the localized message in the error
# details or localize it in the client. The optional error details may contain
# arbitrary information about the error. There is a predefined set of error
# detail types in the package google.rpc that can be used for common error
# conditions.Language mappingThe Status message is the logical representation of
# the error model, but it is not necessarily the actual wire format. When the
# Status message is exposed in different client libraries and different wire
# protocols, it can be mapped differently. For example, it will likely be mapped
# to some exceptions in Java, but more likely mapped to some error codes in C.
# Other usesThe error model and the Status message can be used in a variety of
# environments, either with or without APIs, to provide a consistent developer
# experience across different environments.Example uses of this error model
# include:
# Partial errors. If a service needs to return partial errors to the client, it
# may embed the Status in the normal response to indicate the partial errors.
# Workflow errors. A typical workflow has multiple steps. Each step may have a
# Status message for error reporting.
# Batch operations. If a client uses batch request and batch response, the
# Status message should be used directly inside batch response, one for each
# error sub-response.
# Asynchronous operations. If an API call embeds asynchronous operation results
# in its response, the status of those operations should be represented directly
# using the Status message.
# Logging. If some API errors are stored in logs, the message Status could be
# used directly after any stripping needed for security/privacy reasons.
# (https://github.com/grpc). Each Status message contains three pieces of data:
# error code, error message, and error details.You can find out more about this
# error model and how to work with it in the API Design Guide (https://cloud.
# google.com/apis/design/errors).
class Status
include Google::Apis::Core::Hashable

2
generated/google/apis/appengine_v1beta.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://cloud.google.com/appengine/docs/admin-api/
module AppengineV1beta
VERSION = 'V1beta'
REVISION = '20190503'
REVISION = '20190531'
# View and manage your applications deployed on Google App Engine
AUTH_APPENGINE_ADMIN = 'https://www.googleapis.com/auth/appengine.admin'

72
generated/google/apis/appengine_v1beta/classes.rb
View File

@ -1913,38 +1913,10 @@ module Google
# 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 needsOverviewThe Status message contains
# three pieces of data: error code, error message, and error details. The error
# code should be an enum value of google.rpc.Code, but it may accept additional
# error codes if needed. The error message should be a developer-facing English
# message that helps developers understand and resolve the error. If a localized
# user-facing error message is needed, put the localized message in the error
# details or localize it in the client. The optional error details may contain
# arbitrary information about the error. There is a predefined set of error
# detail types in the package google.rpc that can be used for common error
# conditions.Language mappingThe Status message is the logical representation of
# the error model, but it is not necessarily the actual wire format. When the
# Status message is exposed in different client libraries and different wire
# protocols, it can be mapped differently. For example, it will likely be mapped
# to some exceptions in Java, but more likely mapped to some error codes in C.
# Other usesThe error model and the Status message can be used in a variety of
# environments, either with or without APIs, to provide a consistent developer
# experience across different environments.Example uses of this error model
# include:
# Partial errors. If a service needs to return partial errors to the client, it
# may embed the Status in the normal response to indicate the partial errors.
# Workflow errors. A typical workflow has multiple steps. Each step may have a
# Status message for error reporting.
# Batch operations. If a client uses batch request and batch response, the
# Status message should be used directly inside batch response, one for each
# error sub-response.
# Asynchronous operations. If an API call embeds asynchronous operation results
# in its response, the status of those operations should be represented directly
# using the Status message.
# Logging. If some API errors are stored in logs, the message Status could be
# used directly after any stripping needed for security/privacy reasons.
# (https://github.com/grpc). Each Status message contains three pieces of data:
# error code, error message, and error details.You can find out more about this
# error model and how to work with it in the API Design Guide (https://cloud.
# google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::AppengineV1beta::Status]
attr_accessor :error
@ -2562,38 +2534,10 @@ module Google
# 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 needsOverviewThe Status message contains
# three pieces of data: error code, error message, and error details. The error
# code should be an enum value of google.rpc.Code, but it may accept additional
# error codes if needed. The error message should be a developer-facing English
# message that helps developers understand and resolve the error. If a localized
# user-facing error message is needed, put the localized message in the error
# details or localize it in the client. The optional error details may contain
# arbitrary information about the error. There is a predefined set of error
# detail types in the package google.rpc that can be used for common error
# conditions.Language mappingThe Status message is the logical representation of
# the error model, but it is not necessarily the actual wire format. When the
# Status message is exposed in different client libraries and different wire
# protocols, it can be mapped differently. For example, it will likely be mapped
# to some exceptions in Java, but more likely mapped to some error codes in C.
# Other usesThe error model and the Status message can be used in a variety of
# environments, either with or without APIs, to provide a consistent developer
# experience across different environments.Example uses of this error model
# include:
# Partial errors. If a service needs to return partial errors to the client, it
# may embed the Status in the normal response to indicate the partial errors.
# Workflow errors. A typical workflow has multiple steps. Each step may have a
# Status message for error reporting.
# Batch operations. If a client uses batch request and batch response, the
# Status message should be used directly inside batch response, one for each
# error sub-response.
# Asynchronous operations. If an API call embeds asynchronous operation results
# in its response, the status of those operations should be represented directly
# using the Status message.
# Logging. If some API errors are stored in logs, the message Status could be
# used directly after any stripping needed for security/privacy reasons.
# (https://github.com/grpc). Each Status message contains three pieces of data:
# error code, error message, and error details.You can find out more about this
# error model and how to work with it in the API Design Guide (https://cloud.
# google.com/apis/design/errors).
class Status
include Google::Apis::Core::Hashable

2
generated/google/apis/cloudtasks_v2beta2.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://cloud.google.com/tasks/
module CloudtasksV2beta2
VERSION = 'V2beta2'
REVISION = '20190513'
REVISION = '20190531'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

82
generated/google/apis/cloudtasks_v2beta2/classes.rb
View File

@ -404,43 +404,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `responseStatus`
# @return [Google::Apis::CloudtasksV2beta2::Status]
attr_accessor :response_status
@ -1512,43 +1479,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
class Status
include Google::Apis::Core::Hashable

2
generated/google/apis/container_v1beta1.rb
View File

@ -26,7 +26,7 @@ module Google
# @see https://cloud.google.com/container-engine/
module ContainerV1beta1
VERSION = 'V1beta1'
REVISION = '20190524'
REVISION = '20190527'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

6
generated/google/apis/container_v1beta1/classes.rb
View File

@ -2171,6 +2171,12 @@ module Google
# "kube-env"
# "startup-script"
# "user-data"
# "disable-address-manager"
# "windows-startup-script-ps1"
# "common-psm1"
# "k8s-node-setup-psm1"
# "install-ssh-psm1"
# "user-profile-psm1"
# Values are free-form strings, and only have meaning as interpreted by
# the image running in the instance. The only restriction placed on them is
# that each value's size must be less than or equal to 32 KB.

2
generated/google/apis/genomics_v1.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://cloud.google.com/genomics
module GenomicsV1
VERSION = 'V1'
REVISION = '20190507'
REVISION = '20190606'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

82
generated/google/apis/genomics_v1/classes.rb
View File

@ -316,43 +316,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::GenomicsV1::Status]
attr_accessor :error
@ -570,43 +537,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
class Status
include Google::Apis::Core::Hashable

2
generated/google/apis/genomics_v1alpha2.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://cloud.google.com/genomics
module GenomicsV1alpha2
VERSION = 'V1alpha2'
REVISION = '20190507'
REVISION = '20190606'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

82
generated/google/apis/genomics_v1alpha2/classes.rb
View File

@ -569,43 +569,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::GenomicsV1alpha2::Status]
attr_accessor :error
@ -1324,43 +1291,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
class Status
include Google::Apis::Core::Hashable

2
generated/google/apis/genomics_v2alpha1.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://cloud.google.com/genomics
module GenomicsV2alpha1
VERSION = 'V2alpha1'
REVISION = '20190507'
REVISION = '20190606'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

127
generated/google/apis/genomics_v2alpha1/classes.rb
View File

@ -136,7 +136,7 @@ module Google
# An optional name for the container. The container hostname will be set to
# this name, making it useful for inter-container communication. The name
# must contain only upper and lowercase alphanumeric characters and hypens
# and cannot start with a hypen.
# and cannot start with a hyphen.
# Corresponds to the JSON property `name`
# @return [String]
attr_accessor :name
@ -222,43 +222,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `result`
# @return [Google::Apis::GenomicsV2alpha1::Status]
attr_accessor :result
@ -479,7 +446,7 @@ module Google
# A user-supplied name for the disk. Used when mounting the disk into
# actions. The name must contain only upper and lowercase alphanumeric
# characters and hypens and cannot start with a hypen.
# characters and hypens and cannot start with a hyphen.
# Corresponds to the JSON property `name`
# @return [String]
attr_accessor :name
@ -788,43 +755,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::GenomicsV2alpha1::Status]
attr_accessor :error
@ -1213,43 +1147,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
class Status
include Google::Apis::Core::Hashable

7
generated/google/apis/monitoring_v3.rb
View File

@ -22,12 +22,15 @@ module Google
#
# Manages your Stackdriver Monitoring data and configurations. Most projects
# must be associated with a Stackdriver account, with a few exceptions as noted
# on the individual method pages.
# on the individual method pages. The table entries below are presented in
# alphabetical order, not in order of common use. For explanations of the
# concepts found in the table entries, read the Stackdriver Monitoring
# documentation.
#
# @see https://cloud.google.com/monitoring/api/
module MonitoringV3
VERSION = 'V3'
REVISION = '20190526'
REVISION = '20190604'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

110
generated/google/apis/monitoring_v3/classes.rb
View File

@ -344,38 +344,10 @@ module Google
# 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 needsOverviewThe Status message contains
# three pieces of data: error code, error message, and error details. The error
# code should be an enum value of google.rpc.Code, but it may accept additional
# error codes if needed. The error message should be a developer-facing English
# message that helps developers understand and resolve the error. If a localized
# user-facing error message is needed, put the localized message in the error
# details or localize it in the client. The optional error details may contain
# arbitrary information about the error. There is a predefined set of error
# detail types in the package google.rpc that can be used for common error
# conditions.Language mappingThe Status message is the logical representation of
# the error model, but it is not necessarily the actual wire format. When the
# Status message is exposed in different client libraries and different wire
# protocols, it can be mapped differently. For example, it will likely be mapped
# to some exceptions in Java, but more likely mapped to some error codes in C.
# Other usesThe error model and the Status message can be used in a variety of
# environments, either with or without APIs, to provide a consistent developer
# experience across different environments.Example uses of this error model
# include:
# Partial errors. If a service needs to return partial errors to the client, it
# may embed the Status in the normal response to indicate the partial errors.
# Workflow errors. A typical workflow has multiple steps. Each step may have a
# Status message for error reporting.
# Batch operations. If a client uses batch request and batch response, the
# Status message should be used directly inside batch response, one for each
# error sub-response.
# Asynchronous operations. If an API call embeds asynchronous operation results
# in its response, the status of those operations should be represented directly
# using the Status message.
# Logging. If some API errors are stored in logs, the message Status could be
# used directly after any stripping needed for security/privacy reasons.
# (https://github.com/grpc). Each Status message contains three pieces of data:
# error code, error message, and error details.You can find out more about this
# error model and how to work with it in the API Design Guide (https://cloud.
# google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::MonitoringV3::Status]
attr_accessor :error
@ -442,38 +414,10 @@ module Google
# 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 needsOverviewThe Status message contains
# three pieces of data: error code, error message, and error details. The error
# code should be an enum value of google.rpc.Code, but it may accept additional
# error codes if needed. The error message should be a developer-facing English
# message that helps developers understand and resolve the error. If a localized
# user-facing error message is needed, put the localized message in the error
# details or localize it in the client. The optional error details may contain
# arbitrary information about the error. There is a predefined set of error
# detail types in the package google.rpc that can be used for common error
# conditions.Language mappingThe Status message is the logical representation of
# the error model, but it is not necessarily the actual wire format. When the
# Status message is exposed in different client libraries and different wire
# protocols, it can be mapped differently. For example, it will likely be mapped
# to some exceptions in Java, but more likely mapped to some error codes in C.
# Other usesThe error model and the Status message can be used in a variety of
# environments, either with or without APIs, to provide a consistent developer
# experience across different environments.Example uses of this error model
# include:
# Partial errors. If a service needs to return partial errors to the client, it
# may embed the Status in the normal response to indicate the partial errors.
# Workflow errors. A typical workflow has multiple steps. Each step may have a
# Status message for error reporting.
# Batch operations. If a client uses batch request and batch response, the
# Status message should be used directly inside batch response, one for each
# error sub-response.
# Asynchronous operations. If an API call embeds asynchronous operation results
# in its response, the status of those operations should be represented directly
# using the Status message.
# Logging. If some API errors are stored in logs, the message Status could be
# used directly after any stripping needed for security/privacy reasons.
# (https://github.com/grpc). Each Status message contains three pieces of data:
# error code, error message, and error details.You can find out more about this
# error model and how to work with it in the API Design Guide (https://cloud.
# google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::MonitoringV3::Status]
attr_accessor :error
@ -2028,7 +1972,7 @@ module Google
# the use of the labels "instance_id" and "zone" to identify particular VM
# instances.Different APIs can support different monitored resource types. APIs
# generally provide a list method that returns the monitored resource
# descriptors used by the API.
# descriptors used by the API.Next ID: 10
class MonitoredResourceDescriptor
include Google::Apis::Core::Hashable
@ -2482,38 +2426,10 @@ module Google
# 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 needsOverviewThe Status message contains
# three pieces of data: error code, error message, and error details. The error
# code should be an enum value of google.rpc.Code, but it may accept additional
# error codes if needed. The error message should be a developer-facing English
# message that helps developers understand and resolve the error. If a localized
# user-facing error message is needed, put the localized message in the error
# details or localize it in the client. The optional error details may contain
# arbitrary information about the error. There is a predefined set of error
# detail types in the package google.rpc that can be used for common error
# conditions.Language mappingThe Status message is the logical representation of
# the error model, but it is not necessarily the actual wire format. When the
# Status message is exposed in different client libraries and different wire
# protocols, it can be mapped differently. For example, it will likely be mapped
# to some exceptions in Java, but more likely mapped to some error codes in C.
# Other usesThe error model and the Status message can be used in a variety of
# environments, either with or without APIs, to provide a consistent developer
# experience across different environments.Example uses of this error model
# include:
# Partial errors. If a service needs to return partial errors to the client, it
# may embed the Status in the normal response to indicate the partial errors.
# Workflow errors. A typical workflow has multiple steps. Each step may have a
# Status message for error reporting.
# Batch operations. If a client uses batch request and batch response, the
# Status message should be used directly inside batch response, one for each
# error sub-response.
# Asynchronous operations. If an API call embeds asynchronous operation results
# in its response, the status of those operations should be represented directly
# using the Status message.
# Logging. If some API errors are stored in logs, the message Status could be
# used directly after any stripping needed for security/privacy reasons.
# (https://github.com/grpc). Each Status message contains three pieces of data:
# error code, error message, and error details.You can find out more about this
# error model and how to work with it in the API Design Guide (https://cloud.
# google.com/apis/design/errors).
class Status
include Google::Apis::Core::Hashable

5
generated/google/apis/monitoring_v3/service.rb
View File

@ -24,7 +24,10 @@ module Google
#
# Manages your Stackdriver Monitoring data and configurations. Most projects
# must be associated with a Stackdriver account, with a few exceptions as noted
# on the individual method pages.
# on the individual method pages. The table entries below are presented in
# alphabetical order, not in order of common use. For explanations of the
# concepts found in the table entries, read the Stackdriver Monitoring
# documentation.
#
# @example
# require 'google/apis/monitoring_v3'

2
generated/google/apis/remotebuildexecution_v1.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://cloud.google.com/remote-build-execution/docs/
module RemotebuildexecutionV1
VERSION = 'V1'
REVISION = '20190521'
REVISION = '20190604'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

205
generated/google/apis/remotebuildexecution_v1/classes.rb
View File

@ -801,43 +801,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `status`
# @return [Google::Apis::RemotebuildexecutionV1::GoogleRpcStatus]
attr_accessor :status
@ -2538,43 +2505,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `status`
# @return [Google::Apis::RemotebuildexecutionV1::GoogleRpcStatus]
attr_accessor :status
@ -3207,43 +3141,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `status`
# @return [Google::Apis::RemotebuildexecutionV1::GoogleRpcStatus]
attr_accessor :status
@ -3672,43 +3573,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::RemotebuildexecutionV1::GoogleRpcStatus]
attr_accessor :error
@ -3775,43 +3643,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
class GoogleRpcStatus
include Google::Apis::Core::Hashable

2
generated/google/apis/remotebuildexecution_v1alpha.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://cloud.google.com/remote-build-execution/docs/
module RemotebuildexecutionV1alpha
VERSION = 'V1alpha'
REVISION = '20190521'
REVISION = '20190604'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

205
generated/google/apis/remotebuildexecution_v1alpha/classes.rb
View File

@ -801,43 +801,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `status`
# @return [Google::Apis::RemotebuildexecutionV1alpha::GoogleRpcStatus]
attr_accessor :status
@ -2519,43 +2486,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `status`
# @return [Google::Apis::RemotebuildexecutionV1alpha::GoogleRpcStatus]
attr_accessor :status
@ -3188,43 +3122,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `status`
# @return [Google::Apis::RemotebuildexecutionV1alpha::GoogleRpcStatus]
attr_accessor :status
@ -3615,43 +3516,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::RemotebuildexecutionV1alpha::GoogleRpcStatus]
attr_accessor :error
@ -3699,43 +3567,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
class GoogleRpcStatus
include Google::Apis::Core::Hashable

2
generated/google/apis/remotebuildexecution_v2.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://cloud.google.com/remote-build-execution/docs/
module RemotebuildexecutionV2
VERSION = 'V2'
REVISION = '20190521'
REVISION = '20190604'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

287
generated/google/apis/remotebuildexecution_v2/classes.rb
View File

@ -472,43 +472,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `status`
# @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
attr_accessor :status
@ -654,43 +621,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `status`
# @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
attr_accessor :status
@ -1255,43 +1189,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `status`
# @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
attr_accessor :status
@ -3272,43 +3173,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `status`
# @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
attr_accessor :status
@ -3941,43 +3809,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `status`
# @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
attr_accessor :status
@ -4368,43 +4203,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::RemotebuildexecutionV2::GoogleRpcStatus]
attr_accessor :error
@ -4452,43 +4254,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
class GoogleRpcStatus
include Google::Apis::Core::Hashable

2
generated/google/apis/runtimeconfig_v1.rb
View File

@ -28,7 +28,7 @@ module Google
# @see https://cloud.google.com/deployment-manager/runtime-configurator/
module RuntimeconfigV1
VERSION = 'V1'
REVISION = '20190506'
REVISION = '20190603'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

82
generated/google/apis/runtimeconfig_v1/classes.rb
View File

@ -94,43 +94,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::RuntimeconfigV1::Status]
attr_accessor :error
@ -178,43 +145,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
class Status
include Google::Apis::Core::Hashable

2
generated/google/apis/runtimeconfig_v1beta1.rb
View File

@ -28,7 +28,7 @@ module Google
# @see https://cloud.google.com/deployment-manager/runtime-configurator/
module RuntimeconfigV1beta1
VERSION = 'V1beta1'
REVISION = '20190506'
REVISION = '20190603'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

123
generated/google/apis/runtimeconfig_v1beta1/classes.rb
View File

@ -309,43 +309,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::RuntimeconfigV1beta1::Status]
attr_accessor :error
@ -560,43 +527,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
class Status
include Google::Apis::Core::Hashable
@ -775,43 +709,10 @@ module Google
# 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
# # Overview
# The `Status` message contains three pieces of data: error code, error
# message, and error details. The error code should be an enum value of
# google.rpc.Code, but it may accept additional error codes if needed. The
# error message should be a developer-facing English message that helps
# developers *understand* and *resolve* the error. If a localized user-facing
# error message is needed, put the localized message in the error details or
# localize it in the client. The optional error details may contain arbitrary
# information about the error. There is a predefined set of error detail types
# in the package `google.rpc` that can be used for common error conditions.
# # Language mapping
# The `Status` message is the logical representation of the error model, but it
# is not necessarily the actual wire format. When the `Status` message is
# exposed in different client libraries and different wire protocols, it can be
# mapped differently. For example, it will likely be mapped to some exceptions
# in Java, but more likely mapped to some error codes in C.
# # Other uses
# The error model and the `Status` message can be used in a variety of
# environments, either with or without APIs, to provide a
# consistent developer experience across different environments.
# Example uses of this error model include:
# - Partial errors. If a service needs to return partial errors to the client,
# it may embed the `Status` in the normal response to indicate the partial
# errors.
# - Workflow errors. A typical workflow has multiple steps. Each step may
# have a `Status` message for error reporting.
# - Batch operations. If a client uses batch request and batch response, the
# `Status` message should be used directly inside batch response, one for
# each error sub-response.
# - Asynchronous operations. If an API call embeds asynchronous operation
# results in its response, the status of those operations should be
# represented directly using the `Status` message.
# - Logging. If some API errors are stored in logs, the message `Status` could
# be used directly after any stripping needed for security/privacy reasons.
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
# three pieces of data: error code, error message, and error details.
# You can find out more about this error model and how to work with it in the
# [API Design Guide](https://cloud.google.com/apis/design/errors).
# Corresponds to the JSON property `error`
# @return [Google::Apis::RuntimeconfigV1beta1::Status]
attr_accessor :error

2
generated/google/apis/serviceconsumermanagement_v1.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://cloud.google.com/service-consumer-management/docs/overview
module ServiceconsumermanagementV1
VERSION = 'V1'
REVISION = '20190530'
REVISION = '20190604'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

1
generated/google/apis/serviceconsumermanagement_v1/classes.rb
View File

@ -2138,6 +2138,7 @@ module Google
# Different APIs can support different monitored resource types. APIs generally
# provide a `list` method that returns the monitored resource descriptors used
# by the API.
# Next ID: 10
class MonitoredResourceDescriptor
include Google::Apis::Core::Hashable

2
generated/google/apis/servicenetworking_v1.rb
View File

@ -26,7 +26,7 @@ module Google
# @see https://cloud.google.com/service-infrastructure/docs/service-networking/getting-started
module ServicenetworkingV1
VERSION = 'V1'
REVISION = '20190530'
REVISION = '20190604'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

1
generated/google/apis/servicenetworking_v1/classes.rb
View File

@ -2153,6 +2153,7 @@ module Google
# Different APIs can support different monitored resource types. APIs generally
# provide a `list` method that returns the monitored resource descriptors used
# by the API.
# Next ID: 10
class MonitoredResourceDescriptor
include Google::Apis::Core::Hashable

2
generated/google/apis/servicenetworking_v1beta.rb
View File

@ -26,7 +26,7 @@ module Google
# @see https://cloud.google.com/service-infrastructure/docs/service-networking/getting-started
module ServicenetworkingV1beta
VERSION = 'V1beta'
REVISION = '20190530'
REVISION = '20190604'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

1
generated/google/apis/servicenetworking_v1beta/classes.rb
View File

@ -2093,6 +2093,7 @@ module Google
# Different APIs can support different monitored resource types. APIs generally
# provide a `list` method that returns the monitored resource descriptors used
# by the API.
# Next ID: 10
class MonitoredResourceDescriptor
include Google::Apis::Core::Hashable

2
generated/google/apis/serviceusage_v1.rb
View File

@ -27,7 +27,7 @@ module Google
# @see https://cloud.google.com/service-usage/
module ServiceusageV1
VERSION = 'V1'
REVISION = '20190530'
REVISION = '20190605'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

1
generated/google/apis/serviceusage_v1/classes.rb
View File

@ -2847,6 +2847,7 @@ module Google
# Different APIs can support different monitored resource types. APIs generally
# provide a `list` method that returns the monitored resource descriptors used
# by the API.
# Next ID: 10
class MonitoredResourceDescriptor
include Google::Apis::Core::Hashable

2
generated/google/apis/serviceusage_v1beta1.rb
View File

@ -27,7 +27,7 @@ module Google
# @see https://cloud.google.com/service-usage/
module ServiceusageV1beta1
VERSION = 'V1beta1'
REVISION = '20190530'
REVISION = '20190605'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

1
generated/google/apis/serviceusage_v1beta1/classes.rb
View File

@ -2823,6 +2823,7 @@ module Google
# Different APIs can support different monitored resource types. APIs generally
# provide a `list` method that returns the monitored resource descriptors used
# by the API.
# Next ID: 10
class MonitoredResourceDescriptor
include Google::Apis::Core::Hashable

2
generated/google/apis/storage_v1.rb
View File

@ -25,7 +25,7 @@ module Google
# @see https://developers.google.com/storage/docs/json_api/
module StorageV1
VERSION = 'V1'
REVISION = '20190426'
REVISION = '20190523'
# View and manage your data across Google Cloud Platform services
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

7
generated/google/apis/storage_v1/classes.rb
View File

@ -987,12 +987,6 @@ module Google
# @return [String]
attr_accessor :expression
# The kind of item this is. For storage, this is always storage#expr. This field
# is ignored on input.
# Corresponds to the JSON property `kind`
# @return [String]
attr_accessor :kind
# An optional string indicating the location of the expression for error
# reporting, e.g. a file name and a position in the file.
# Corresponds to the JSON property `location`
@ -1013,7 +1007,6 @@ module Google
def update!(**args)
@description = args[:description] if args.key?(:description)
@expression = args[:expression] if args.key?(:expression)
@kind = args[:kind] if args.key?(:kind)
@location = args[:location] if args.key?(:location)
@title = args[:title] if args.key?(:title)
end

1
generated/google/apis/storage_v1/representations.rb
View File

@ -529,7 +529,6 @@ module Google
class Representation < Google::Apis::Core::JsonRepresentation
property :description, as: 'description'
property :expression, as: 'expression'
property :kind, as: 'kind'
property :location, as: 'location'
property :title, as: 'title'
end