Package cloud.google.com/go (v0.90.0) Stay organized with collections Save and categorize content based on your preferences.
- 0.123.0 (latest)
- 0.122.0
- 0.121.6
- 0.120.1
- 0.119.0
- 0.118.3
- 0.117.0
- 0.116.0
- 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
Package cloud is the root of the packages used to access Google CloudServices. Seehttps://godoc.org/cloud.google.com/go for a full listof sub-packages.
Client Options
All clients in sub-packages are configurable via client options. These options aredescribed here:https://godoc.org/google.golang.org/api/option.
Authentication and Authorization
All the clients in sub-packages support authentication via Google Application DefaultCredentials (seehttps://cloud.google.com/docs/authentication/production), orby providing a JSON key file for a Service Account. See the authentication examplesin this package for details.
Timeouts and Cancellation
By default, non-streaming methods, like Create or Get, will have a default deadline applied to thecontext provided at call time, unless a context deadline is already set. Streamingmethods have no default deadline and will run indefinitely. To set timeouts orarrange for cancellation, use contexts. See the examples for details. Transienterrors will be retried when correctness allows.
To opt out of default deadlines, set the temporary environment variableGOOGLE_API_GO_EXPERIMENTAL_DISABLE_DEFAULT_DEADLINE to "true" prior to clientcreation. This affects all Google Cloud Go client libraries. This opt-outmechanism will be removed in a future release. File an issue athttps://github.com/googleapis/google-cloud-go if the default deadlinescannot work for you.
Do not attempt to control the initial connection (dialing) of a service by setting atimeout on the context passed to NewClient. Dialing is non-blocking, so timeoutswould be ineffective and would only interfere with credential refreshing, which usesthe same context.
Connection Pooling
Connection pooling differs in clients based on their transport. Cloudclients either rely on HTTP or gRPC transports to communicatewith Google Cloud.
Cloud clients that use HTTP (bigquery, compute, storage, and translate) rely on theunderlying HTTP transport to cache connections for later re-use. These are cached tothe default http.MaxIdleConns and http.MaxIdleConnsPerHost settings inhttp.DefaultTransport.
For gRPC clients (all others in this repo), connection pooling is configurable. Usersof cloud client libraries may specify option.WithGRPCConnectionPool(n) as a clientoption to NewClient calls. This configures the underlying gRPC connections to bepooled 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 tohang, because gRPC retries indefinitely. Seehttps://github.com/googleapis/google-cloud-go/issues/928for more information.
Debugging
To see gRPC logs, set the environment variable GRPC_GO_LOG_SEVERITY_LEVEL. Seehttps://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 agrpc.Status. Converting your errors to this type can be a useful to getmore information about what went wrong while debugging.
iferr!={ifs,ok:=status.FromError(err);ok{log.Println(s.Message())for_,d:=ranges.Proto().Details{log.Println(d)}}}
Client Stability
Clients in this repository are considered alpha or beta unless otherwisemarked as stable in the README.md. Semver is not used to communicate stabilityof clients.
Alpha and beta clients may change or go away without notice.
Clients marked stable will maintain compatibility with future versions for aslong as we can reasonably sustain. Incompatible changes might be made in somesituations, including:
- Security bugs may prompt backwards-incompatible changes.
- Situations in which components are no longer feasible to maintain withoutmaking 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 EXPERIMENTALand subject to change or removal without notice."
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-10-30 UTC.