From 827d93636fe93fbec2e7b6371586ce9477c70f59 Mon Sep 17 00:00:00 2001 From: Google APIs Date: Wed, 5 Jun 2019 00:37:20 +0000 Subject: [PATCH] Autogenerated update (2019-06-05) Update: - cloudbuild_v1 - cloudtasks_v2 - cloudtasks_v2beta3 - language_v1 - language_v1beta1 - language_v1beta2 - ml_v1 - storagetransfer_v1 - youtube_partner_v1 --- generated/google/apis/cloudbuild_v1.rb | 2 +- .../google/apis/cloudbuild_v1/classes.rb | 82 ++------------ generated/google/apis/cloudtasks_v2.rb | 2 +- .../google/apis/cloudtasks_v2/classes.rb | 82 ++------------ .../google/apis/cloudtasks_v2/service.rb | 3 +- generated/google/apis/cloudtasks_v2beta3.rb | 2 +- .../google/apis/cloudtasks_v2beta3/classes.rb | 90 ++------------- .../google/apis/cloudtasks_v2beta3/service.rb | 3 +- generated/google/apis/language_v1.rb | 2 +- generated/google/apis/language_v1/classes.rb | 41 +------ generated/google/apis/language_v1beta1.rb | 2 +- .../google/apis/language_v1beta1/classes.rb | 41 +------ generated/google/apis/language_v1beta2.rb | 2 +- .../google/apis/language_v1beta2/classes.rb | 41 +------ generated/google/apis/ml_v1.rb | 2 +- generated/google/apis/ml_v1/classes.rb | 104 +++++------------- .../google/apis/ml_v1/representations.rb | 2 + generated/google/apis/storagetransfer_v1.rb | 2 +- .../google/apis/storagetransfer_v1/classes.rb | 92 +++------------- generated/google/apis/youtube_partner_v1.rb | 4 +- .../google/apis/youtube_partner_v1/service.rb | 2 +- 21 files changed, 92 insertions(+), 511 deletions(-) diff --git a/generated/google/apis/cloudbuild_v1.rb b/generated/google/apis/cloudbuild_v1.rb index 6bdc67eb9..52de77e46 100644 --- a/generated/google/apis/cloudbuild_v1.rb +++ b/generated/google/apis/cloudbuild_v1.rb @@ -25,7 +25,7 @@ module Google # @see https://cloud.google.com/cloud-build/docs/ module CloudbuildV1 VERSION = 'V1' - REVISION = '20190507' + REVISION = '20190531' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/cloudbuild_v1/classes.rb b/generated/google/apis/cloudbuild_v1/classes.rb index 8a8027998..78bc9984a 100644 --- a/generated/google/apis/cloudbuild_v1/classes.rb +++ b/generated/google/apis/cloudbuild_v1/classes.rb @@ -965,43 +965,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::CloudbuildV1::Status] attr_accessor :error @@ -1321,43 +1288,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 diff --git a/generated/google/apis/cloudtasks_v2.rb b/generated/google/apis/cloudtasks_v2.rb index 50d8555b7..7ebffa285 100644 --- a/generated/google/apis/cloudtasks_v2.rb +++ b/generated/google/apis/cloudtasks_v2.rb @@ -25,7 +25,7 @@ module Google # @see https://cloud.google.com/tasks/ module CloudtasksV2 VERSION = 'V2' - REVISION = '20190513' + REVISION = '20190531' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/cloudtasks_v2/classes.rb b/generated/google/apis/cloudtasks_v2/classes.rb index faa36b1b4..2f8808df7 100644 --- a/generated/google/apis/cloudtasks_v2/classes.rb +++ b/generated/google/apis/cloudtasks_v2/classes.rb @@ -295,43 +295,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::CloudtasksV2::Status] attr_accessor :response_status @@ -1147,43 +1114,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 diff --git a/generated/google/apis/cloudtasks_v2/service.rb b/generated/google/apis/cloudtasks_v2/service.rb index 17410a5c8..1e9bfded2 100644 --- a/generated/google/apis/cloudtasks_v2/service.rb +++ b/generated/google/apis/cloudtasks_v2/service.rb @@ -608,8 +608,7 @@ module Google # Creates a task and adds it to a queue. # Tasks cannot be updated after creation; there is no UpdateTask command. - # * For App Engine queues, the maximum task size is - # 100KB. + # * The maximum task size is 100KB. # @param [String] parent # Required. # The queue name. For example: diff --git a/generated/google/apis/cloudtasks_v2beta3.rb b/generated/google/apis/cloudtasks_v2beta3.rb index d06a5c017..5e5f23255 100644 --- a/generated/google/apis/cloudtasks_v2beta3.rb +++ b/generated/google/apis/cloudtasks_v2beta3.rb @@ -25,7 +25,7 @@ module Google # @see https://cloud.google.com/tasks/ module CloudtasksV2beta3 VERSION = 'V2beta3' - REVISION = '20190513' + REVISION = '20190531' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/cloudtasks_v2beta3/classes.rb b/generated/google/apis/cloudtasks_v2beta3/classes.rb index 00824c1b4..01c350be8 100644 --- a/generated/google/apis/cloudtasks_v2beta3/classes.rb +++ b/generated/google/apis/cloudtasks_v2beta3/classes.rb @@ -339,43 +339,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::CloudtasksV2beta3::Status] attr_accessor :response_status @@ -567,10 +534,6 @@ module Google end # HTTP request. - # Warning: This is an [alpha](https://cloud.google.com/terms/launch-stages) - # feature. If you haven't already joined, you can [use this form to sign - # up](https://docs.google.com/forms/d/e/ - # 1FAIpQLSfc4uEy9CBHKYUSdnY1hdhKDCX7julVZHy3imOiR-XrU7bUNQ/viewform). # The task will be pushed to the worker as an HTTP request. If the worker # or the redirected worker acknowledges the task by returning a successful HTTP # response code ([`200` - `299`]), the task will removed from the queue. If @@ -1397,43 +1360,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 @@ -1579,10 +1509,6 @@ module Google attr_accessor :first_attempt # HTTP request. - # Warning: This is an [alpha](https://cloud.google.com/terms/launch-stages) - # feature. If you haven't already joined, you can [use this form to sign - # up](https://docs.google.com/forms/d/e/ - # 1FAIpQLSfc4uEy9CBHKYUSdnY1hdhKDCX7julVZHy3imOiR-XrU7bUNQ/viewform). # The task will be pushed to the worker as an HTTP request. If the worker # or the redirected worker acknowledges the task by returning a successful HTTP # response code ([`200` - `299`]), the task will removed from the queue. If diff --git a/generated/google/apis/cloudtasks_v2beta3/service.rb b/generated/google/apis/cloudtasks_v2beta3/service.rb index 72d8b7dfb..315a6a455 100644 --- a/generated/google/apis/cloudtasks_v2beta3/service.rb +++ b/generated/google/apis/cloudtasks_v2beta3/service.rb @@ -608,8 +608,7 @@ module Google # Creates a task and adds it to a queue. # Tasks cannot be updated after creation; there is no UpdateTask command. - # * For App Engine queues, the maximum task size is - # 100KB. + # * The maximum task size is 100KB. # @param [String] parent # Required. # The queue name. For example: diff --git a/generated/google/apis/language_v1.rb b/generated/google/apis/language_v1.rb index 92c5f4b96..e2a3a40e9 100644 --- a/generated/google/apis/language_v1.rb +++ b/generated/google/apis/language_v1.rb @@ -27,7 +27,7 @@ module Google # @see https://cloud.google.com/natural-language/ module LanguageV1 VERSION = 'V1' - REVISION = '20190514' + REVISION = '20190603' # Apply machine learning models to reveal the structure and meaning of text AUTH_CLOUD_LANGUAGE = 'https://www.googleapis.com/auth/cloud-language' diff --git a/generated/google/apis/language_v1/classes.rb b/generated/google/apis/language_v1/classes.rb index dafea4249..f56fa961e 100644 --- a/generated/google/apis/language_v1/classes.rb +++ b/generated/google/apis/language_v1/classes.rb @@ -771,43 +771,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 diff --git a/generated/google/apis/language_v1beta1.rb b/generated/google/apis/language_v1beta1.rb index 83901ba09..d659d5f83 100644 --- a/generated/google/apis/language_v1beta1.rb +++ b/generated/google/apis/language_v1beta1.rb @@ -27,7 +27,7 @@ module Google # @see https://cloud.google.com/natural-language/ module LanguageV1beta1 VERSION = 'V1beta1' - REVISION = '20190308' + REVISION = '20190603' # Apply machine learning models to reveal the structure and meaning of text AUTH_CLOUD_LANGUAGE = 'https://www.googleapis.com/auth/cloud-language' diff --git a/generated/google/apis/language_v1beta1/classes.rb b/generated/google/apis/language_v1beta1/classes.rb index 1861fc3bc..8bfae5beb 100644 --- a/generated/google/apis/language_v1beta1/classes.rb +++ b/generated/google/apis/language_v1beta1/classes.rb @@ -622,43 +622,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 diff --git a/generated/google/apis/language_v1beta2.rb b/generated/google/apis/language_v1beta2.rb index 22037499b..fd485c0a9 100644 --- a/generated/google/apis/language_v1beta2.rb +++ b/generated/google/apis/language_v1beta2.rb @@ -27,7 +27,7 @@ module Google # @see https://cloud.google.com/natural-language/ module LanguageV1beta2 VERSION = 'V1beta2' - REVISION = '20190514' + REVISION = '20190603' # Apply machine learning models to reveal the structure and meaning of text AUTH_CLOUD_LANGUAGE = 'https://www.googleapis.com/auth/cloud-language' diff --git a/generated/google/apis/language_v1beta2/classes.rb b/generated/google/apis/language_v1beta2/classes.rb index 13278c498..d552879c5 100644 --- a/generated/google/apis/language_v1beta2/classes.rb +++ b/generated/google/apis/language_v1beta2/classes.rb @@ -778,43 +778,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 diff --git a/generated/google/apis/ml_v1.rb b/generated/google/apis/ml_v1.rb index 64acf30f6..794e7917c 100644 --- a/generated/google/apis/ml_v1.rb +++ b/generated/google/apis/ml_v1.rb @@ -25,7 +25,7 @@ module Google # @see https://cloud.google.com/ml/ module MlV1 VERSION = 'V1' - REVISION = '20190524' + REVISION = '20190530' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/ml_v1/classes.rb b/generated/google/apis/ml_v1/classes.rb index 9c822bdde..52956a6ab 100644 --- a/generated/google/apis/ml_v1/classes.rb +++ b/generated/google/apis/ml_v1/classes.rb @@ -392,9 +392,9 @@ module Google # @return [String] attr_accessor :goal - # Optional. The Tensorflow summary tag name to use for optimizing trials. For - # current versions of Tensorflow, this tag name should exactly match what is - # shown in Tensorboard, including all scopes. For versions of Tensorflow + # Optional. The TensorFlow summary tag name to use for optimizing trials. For + # current versions of TensorFlow, this tag name should exactly match what is + # shown in TensorBoard, including all scopes. For versions of TensorFlow # prior to 0.12, this should be only the tag passed to tf.Summary. # By default, "training/hptuning/metric" will be used. # Corresponds to the JSON property `hyperparameterMetricTag` @@ -1336,6 +1336,11 @@ module Google # @return [String] attr_accessor :master_type + # Optional. The maximum job running time. The default is 7 days. + # Corresponds to the JSON property `maxRunningTime` + # @return [String] + attr_accessor :max_running_time + # Required. The Google Cloud Storage location of the packages with # the training program and any additional dependencies. # The maximum number of package URIs is 100. @@ -1449,6 +1454,7 @@ module Google @job_dir = args[:job_dir] if args.key?(:job_dir) @master_config = args[:master_config] if args.key?(:master_config) @master_type = args[:master_type] if args.key?(:master_type) + @max_running_time = args[:max_running_time] if args.key?(:max_running_time) @package_uris = args[:package_uris] if args.key?(:package_uris) @parameter_server_config = args[:parameter_server_config] if args.key?(:parameter_server_config) @parameter_server_count = args[:parameter_server_count] if args.key?(:parameter_server_count) @@ -1484,6 +1490,15 @@ module Google # @return [Float] attr_accessor :consumed_ml_units + # The TensorFlow summary tag name used for optimizing hyperparameter tuning + # trials. See + # [`HyperparameterSpec.hyperparameterMetricTag`](#HyperparameterSpec.FIELDS. + # hyperparameter_metric_tag) + # for more information. Only set for hyperparameter tuning jobs. + # Corresponds to the JSON property `hyperparameterMetricTag` + # @return [String] + attr_accessor :hyperparameter_metric_tag + # Whether this job is a built-in Algorithm job. # Corresponds to the JSON property `isBuiltInAlgorithmJob` # @return [Boolean] @@ -1511,6 +1526,7 @@ module Google @built_in_algorithm_output = args[:built_in_algorithm_output] if args.key?(:built_in_algorithm_output) @completed_trial_count = args[:completed_trial_count] if args.key?(:completed_trial_count) @consumed_ml_units = args[:consumed_ml_units] if args.key?(:consumed_ml_units) + @hyperparameter_metric_tag = args[:hyperparameter_metric_tag] if args.key?(:hyperparameter_metric_tag) @is_built_in_algorithm_job = args[:is_built_in_algorithm_job] if args.key?(:is_built_in_algorithm_job) @is_hyperparameter_tuning_job = args[:is_hyperparameter_tuning_job] if args.key?(:is_hyperparameter_tuning_job) @trials = args[:trials] if args.key?(:trials) @@ -2148,43 +2164,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::MlV1::GoogleRpcStatus] attr_accessor :error @@ -2251,43 +2234,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 diff --git a/generated/google/apis/ml_v1/representations.rb b/generated/google/apis/ml_v1/representations.rb index 4f97b7e01..a66664a4a 100644 --- a/generated/google/apis/ml_v1/representations.rb +++ b/generated/google/apis/ml_v1/representations.rb @@ -551,6 +551,7 @@ module Google property :master_config, as: 'masterConfig', class: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig, decorator: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig::Representation property :master_type, as: 'masterType' + property :max_running_time, as: 'maxRunningTime' collection :package_uris, as: 'packageUris' property :parameter_server_config, as: 'parameterServerConfig', class: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig, decorator: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig::Representation @@ -575,6 +576,7 @@ module Google property :completed_trial_count, :numeric_string => true, as: 'completedTrialCount' property :consumed_ml_units, as: 'consumedMLUnits' + property :hyperparameter_metric_tag, as: 'hyperparameterMetricTag' property :is_built_in_algorithm_job, as: 'isBuiltInAlgorithmJob' property :is_hyperparameter_tuning_job, as: 'isHyperparameterTuningJob' collection :trials, as: 'trials', class: Google::Apis::MlV1::GoogleCloudMlV1HyperparameterOutput, decorator: Google::Apis::MlV1::GoogleCloudMlV1HyperparameterOutput::Representation diff --git a/generated/google/apis/storagetransfer_v1.rb b/generated/google/apis/storagetransfer_v1.rb index eb09e519a..9b5c8e1aa 100644 --- a/generated/google/apis/storagetransfer_v1.rb +++ b/generated/google/apis/storagetransfer_v1.rb @@ -26,7 +26,7 @@ module Google # @see https://cloud.google.com/storage-transfer/docs module StoragetransferV1 VERSION = 'V1' - REVISION = '20190513' + REVISION = '20190603' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/storagetransfer_v1/classes.rb b/generated/google/apis/storagetransfer_v1/classes.rb index bdbb52fe8..d6614c848 100644 --- a/generated/google/apis/storagetransfer_v1/classes.rb +++ b/generated/google/apis/storagetransfer_v1/classes.rb @@ -392,9 +392,10 @@ module Google # If specified, only objects with a `lastModificationTime` on or after # `NOW` - `maxTimeElapsedSinceLastModification` and objects that don't have # a `lastModificationTime` are transferred. - # Note that `NOW` refers to the creation time of the transfer job, and + # Note that, for each `TransferOperation` started by this `TransferJob`, + # `NOW` refers to the `start_time` of the 'TransferOperation`. Also, # `lastModificationTime` refers to the time of the last change to the - # object's content or metadata. Specifically, this would be the `updated` + # object's content or metadata - specifically, this would be the `updated` # property of GCS objects and the `LastModified` field of S3 objects. # Corresponds to the JSON property `maxTimeElapsedSinceLastModification` # @return [String] @@ -403,9 +404,10 @@ module Google # If specified, only objects with a `lastModificationTime` before # `NOW` - `minTimeElapsedSinceLastModification` and objects that don't have a # `lastModificationTime` are transferred. - # Note that `NOW` refers to the creation time of the transfer job, and + # Note that, for each `TransferOperation` started by this `TransferJob`, + # `NOW` refers to the `start_time` of the 'TransferOperation`. Also, # `lastModificationTime` refers to the time of the last change to the - # object's content or metadata. Specifically, this would be the `updated` + # object's content or metadata - specifically, this would be the `updated` # property of GCS objects and the `LastModified` field of S3 objects. # Corresponds to the JSON property `minTimeElapsedSinceLastModification` # @return [String] @@ -439,43 +441,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::StoragetransferV1::Status] attr_accessor :error @@ -593,43 +562,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 diff --git a/generated/google/apis/youtube_partner_v1.rb b/generated/google/apis/youtube_partner_v1.rb index 3450ac75e..87ab7ccae 100644 --- a/generated/google/apis/youtube_partner_v1.rb +++ b/generated/google/apis/youtube_partner_v1.rb @@ -18,14 +18,14 @@ require 'google/apis/youtube_partner_v1/representations.rb' module Google module Apis - # Youtube Content ID API + # YouTube Content ID API # # API for YouTube partners. To use this API a YouTube CMS account is required. # # @see https://developers.google.com/youtube/partner/ module YoutubePartnerV1 VERSION = 'V1' - REVISION = '20190502' + REVISION = '20190603' # View and manage your assets and associated content on YouTube AUTH_YOUTUBEPARTNER = 'https://www.googleapis.com/auth/youtubepartner' diff --git a/generated/google/apis/youtube_partner_v1/service.rb b/generated/google/apis/youtube_partner_v1/service.rb index e108798c8..4abed6fd3 100644 --- a/generated/google/apis/youtube_partner_v1/service.rb +++ b/generated/google/apis/youtube_partner_v1/service.rb @@ -20,7 +20,7 @@ require 'google/apis/errors' module Google module Apis module YoutubePartnerV1 - # Youtube Content ID API + # YouTube Content ID API # # API for YouTube partners. To use this API a YouTube CMS account is required. #