Package cloud.google.com/go (v0.79.0)

Version 0.79.0

• 0.116.0 (latest)
• 0.115.1
• 0.114.0
• 0.113.0
• 0.112.2
• 0.111.0
• 0.110.10
• 0.109.0
• 0.108.0
• 0.107.0
• 0.106.0
• 0.105.0
• 0.104.0
• 0.103.0
• 0.102.1
• 0.101.1
• 0.100.2
• 0.99.0
• 0.98.0
• 0.97.0
• 0.96.0
• 0.95.0
• 0.94.1
• 0.93.3
• 0.92.3
• 0.91.1
• 0.90.0
• 0.89.0
• 0.88.0
• 0.87.0
• 0.86.0
• 0.85.0
• 0.84.0
• 0.83.0
• 0.82.0
• 0.81.0
• 0.80.0
• 0.79.0
• 0.78.0
• 0.77.0
• 0.76.0
• 0.75.0

Note: To get more information about this package, such as access to older versions, view this package on pkg.go.dev.

Package cloud is the root of the packages used to access Google Cloud Services. See https://godoc.org/cloud.google.com/go for a full list of sub-packages.

Client Options

All clients in sub-packages are configurable via client options. These options are described here: https://godoc.org/google.golang.org/api/option.

Authentication and Authorization

All the clients in sub-packages support authentication via Google Application Default Credentials (see https://cloud.google.com/docs/authentication/production), or by providing a JSON key file for a Service Account. See the authentication examples in this package for details.

Timeouts and Cancellation

By default, non-streaming methods, like Create or Get, will have a default deadline applied to the context provided at call time, unless a context deadline is already set. Streaming methods have no default deadline and will run indefinitely. To set timeouts or arrange for cancellation, use contexts. See the examples for details. Transient errors will be retried when correctness allows.

To opt out of default deadlines, set the temporary environment variable GOOGLE_API_GO_EXPERIMENTAL_DISABLE_DEFAULT_DEADLINE to "true" prior to client creation. This affects all Google Cloud Go client libraries. This opt-out mechanism will be removed in a future release. File an issue at https://github.com/googleapis/google-cloud-go if the default deadlines cannot work for you.

Do not attempt to control the initial connection (dialing) of a service by setting a timeout on the context passed to NewClient. Dialing is non-blocking, so timeouts would be ineffective and would only interfere with credential refreshing, which uses the same context.

Connection Pooling

Connection pooling differs in clients based on their transport. Cloud clients either rely on HTTP or gRPC transports to communicate with Google Cloud.

Cloud clients that use HTTP (bigquery, compute, storage, and translate) rely on the underlying HTTP transport to cache connections for later re-use. These are cached to the default http.MaxIdleConns and http.MaxIdleConnsPerHost settings in http.DefaultTransport.

For gRPC clients (all others in this repo), connection pooling is configurable. Users of cloud client libraries may specify option.WithGRPCConnectionPool(n) as a client option to NewClient calls. This configures the underlying gRPC connections to be pooled and addressed in a round robin fashion.

Using the Libraries with Docker

Minimal docker images like Alpine lack CA certificates. This causes RPCs to appear to hang, because gRPC retries indefinitely. See https://github.com/googleapis/google-cloud-go/issues/928 for more information.

Debugging

To see gRPC logs, set the environment variable GRPC_GO_LOG_SEVERITY_LEVEL. See https://godoc.org/google.golang.org/grpc/grpclog for more information.

For HTTP logging, set the GODEBUG environment variable to "http2debug=1" or "http2debug=2".

Inspecting errors

Most of the errors returned by the generated clients can be converted into a grpc.Status. Converting your errors to this type can be a useful to get more information about what went wrong while debugging.

 if err != {
    if s, ok := status.FromError(err); ok {
       log.Println(s.Message())
       for _, d := range s.Proto().Details {
          log.Println(d)
       }
    }
 }

Client Stability

Clients in this repository are considered alpha or beta unless otherwise marked as stable in the README.md. Semver is not used to communicate stability of clients.

Alpha and beta clients may change or go away without notice.

Clients marked stable will maintain compatibility with future versions for as long as we can reasonably sustain. Incompatible changes might be made in some situations, including:

- Security bugs may prompt backwards-incompatible changes.

- Situations in which components are no longer feasible to maintain without making breaking changes, including removal.

- Parts of the client surface may be outright unstable and subject to change. These parts of the surface will be labeled with the note, "It is EXPERIMENTAL and subject to change or removal without notice."