google_api_cloud_build v0.4.0 API Reference
Modules
API calls for all endpoints tagged Operations
.
API calls for all endpoints tagged Projects
.
Handle Tesla connections for GoogleApi.CloudBuild.V1.
Helper functions for deserializing responses into models.
Files in the workspace to upload to Cloud Storage upon successful completion of all build steps.
An artifact that was uploaded during a build. This is a single record in the artifact manifest JSON file.
Artifacts produced by a build that should be uploaded upon successful completion of all build steps.
A build resource in the Cloud Build API. At a high level, a `Build` describes where to find source code, how to build it (for example, the builder image to run on the source), and where to store the built artifacts. Fields can include the following variables, which will be expanded when the build is created: - $PROJECT_ID: the project ID of the build. - $BUILD_ID: the autogenerated ID of the build. - $REPO_NAME: the source repository name specified by RepoSource. - $BRANCH_NAME: the branch name specified by RepoSource. - $TAG_NAME: the tag name specified by RepoSource. - $REVISION_ID or $COMMIT_SHA: the commit SHA specified by RepoSource or resolved from the specified branch or tag. - $SHORT_SHA: first 7 characters of $REVISION_ID or $COMMIT_SHA.
Metadata for build operations.
Optional arguments to enable specific features of builds.
A step in the build pipeline.
Configuration for an automated build in response to source repository changes.
An image built by the pipeline.
Request to cancel an ongoing build.
The request message for Operations.CancelOperation.
A CheckSuiteFilter is a filter that indicates that we should build on all check suite events.
A generic empty message that you can re-use to avoid defining duplicated empty messages in your APIs. A typical example is to use it as the request or the response type of an API method. For instance: service Foo { rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty); } The JSON representation for `Empty` is empty JSON object `{}`.
Container message for hashes of byte content of files, used in SourceProvenance messages to verify integrity of source input to the build.
GitHubEventsConfig describes the configuration of a trigger that creates a build whenever a GitHub event is received. This message is experimental.
Container message for hash values.
Response containing existing `BuildTriggers`.
Response including listed builds.
The response message for Operations.ListOperations.
This resource represents a long-running operation that is the result of a network API call.
PullRequestFilter contains filter properties for matching GitHub Pull Requests.
Push contains filter properties for matching GitHub git pushes.
Location of the source in a Google Cloud Source Repository.
Artifacts created by the build pipeline.
Specifies a build to retry.
Pairs a set of secret environment variables containing encrypted values with the Cloud KMS key to use to decrypt the value.
Location of the source in a supported storage service.
Provenance of the source. Ways to find the original source, or verify that some source was used for this build.
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. 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.
Location of the source in an archive file in Google Cloud Storage.
Start and end times for a build execution phase.
Volume describes a Docker container volume which is mounted into build steps in order to persist files across build step execution.
Helper functions for building Tesla requests.