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

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
This commit is contained in:
Google APIs 2019-06-05 00:37:20 +00:00
parent f5a4a19b68
commit 827d93636f
21 changed files with 92 additions and 511 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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'

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

@ -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

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

@ -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'

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

@ -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

3
generated/google/apis/cloudtasks_v2/service.rb
View File

@ -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:

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

@ -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'

90
generated/google/apis/cloudtasks_v2beta3/classes.rb
View File

@ -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

3
generated/google/apis/cloudtasks_v2beta3/service.rb
View File

@ -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:

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

@ -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'

41
generated/google/apis/language_v1/classes.rb
View File

@ -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

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

@ -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'

41
generated/google/apis/language_v1beta1/classes.rb
View File

@ -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

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

@ -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'

41
generated/google/apis/language_v1beta2/classes.rb
View File

@ -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

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

@ -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'

104
generated/google/apis/ml_v1/classes.rb
View File

@ -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

2
generated/google/apis/ml_v1/representations.rb
View File

@ -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

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

@ -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'

92
generated/google/apis/storagetransfer_v1/classes.rb
View File

@ -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

4
generated/google/apis/youtube_partner_v1.rb
View File

@ -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'

2
generated/google/apis/youtube_partner_v1/service.rb
View File

@ -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.
#