Struct CloudBuild

pub struct CloudBuild { /* private fields */ }

Implements a client for the Cloud Build API.

Service Description

Creates and manages builds on Google Cloud Platform.

The main concept used by this API is a Build, which describes the location of the source to build, how to build the source, and where to store the built artifacts, if any.

A user can list previously-requested builds or get builds by their ID to determine the status of the build.

Configuration

CloudBuild has various configuration parameters, the defaults should work with most applications.

Pooling and Cloning

CloudBuild holds a connection pool internally, it is advised to create one and the reuse it. You do not need to wrap CloudBuild in an Rc or Arc to reuse it, because it already uses an Arc internally.

Implementations

impl CloudBuild

pub async fn new() -> Result<Self>

Creates a new client with the default configuration.

pub async fn new_with_config(conf: ClientConfig) -> Result<Self>

Creates a new client with the specified configuration.

pub fn from_stub<T>(stub: T) -> Self

where T: CloudBuild + 'static,

Creates a new client from the provided stub.

The most common case for calling this function is when mocking the client.

pub fn create_build(&self, project_id: impl Into<String>) -> CreateBuild

Starts a build with the specified configuration.

This method returns a long-running Operation, which includes the build ID. Pass the build ID to GetBuild to determine the build status (such as SUCCESS or FAILURE).

Long running operations

Calling poller() on the resulting builder returns an implementation of the lro::Poller trait. You need to call Poller::poll on this Poller at least once to start the LRO. You may periodically poll this object to find the status of the operation. The poller automatically extract the final response value and any intermediate metadata values.

Calling send() on the resulting builder starts a LRO (long-Running Operation). LROs run in the background, and the application may poll them periodically to find out if they have succeeded, or failed. See below for instructions on how to manually use the resulting Operation. We recommend poller() in favor of send().

Polling until completion

Applications that do not care about intermediate results in a long-running operation may use the until_done() function:

async fn wait(
    mut poller: impl lro::Poller<model::Build, model::BuildOperationMetadata>
) -> Result<model::Build> {
    poller.until_done().await
}

This will wait until the LRO completes (successfully or with an error). Applications can set the PollingPolicy and PollingBackoffPolicy to control for how long the function runs.

Polling with detailed metadata updates

Using the result of poller() follows a common pattern:

async fn wait(
    mut poller: impl lro::Poller<model::Build, model::BuildOperationMetadata>
) -> Result<model::Build> {
    while let Some(p) = poller.poll().await {
        match p {
            lro::PollingResult::Completed(r) => { return r; },
            lro::PollingResult::InProgress(m) => { println!("in progress {m:?}"); },
            lro::PollingResult::PollingError(_) => { /* ignored */ },
        }
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
    Err(gax::error::Error::other("LRO never completed"))
}

Manually polling long-running operations

If you call send(), you need to examine the contents of the resulting Operation to determine the result of the operation.

If the done field is true, the operation has completed. The result field contains the final response, this will be a crate::model::Build (as an Any), or the error (as a Status).

If the done field is false, the operation has not completed. The operation may also include a crate::model::BuildOperationMetadata value in the metadata field. This value would also be encoded as an Any. The metadata may include information about how much progress the LRO has made.

To find out if the operation has completed, use the get_operation method and repeat the steps outlined above.

Note that most errors on get_operation do not indicate that the long-running operation failed. Long-running operation failures return the error status in the result field.

pub fn get_build( &self, project_id: impl Into<String>, id: impl Into<String>, ) -> GetBuild

Returns information about a previously requested build.

The Build that is returned includes its status (such as SUCCESS, FAILURE, or WORKING), and timing information.

pub fn list_builds(&self, project_id: impl Into<String>) -> ListBuilds

Lists previously requested builds.

Previously requested builds may still be in-progress, or may have finished successfully or unsuccessfully.

pub fn cancel_build( &self, project_id: impl Into<String>, id: impl Into<String>, ) -> CancelBuild

Cancels a build in progress.

pub fn retry_build( &self, project_id: impl Into<String>, id: impl Into<String>, ) -> RetryBuild

Creates a new build based on the specified build.

This method creates a new build using the original build request, which may or may not result in an identical build.

For triggered builds:

• Triggered builds resolve to a precise revision; therefore a retry of a triggered build will result in a build that uses the same revision.

For non-triggered builds that specify RepoSource:

• If the original build built from the tip of a branch, the retried build will build from the tip of that branch, which may not be the same revision as the original build.
• If the original build specified a commit sha or revision ID, the retried build will use the identical source.

For builds that specify StorageSource:

• If the original build pulled source from Cloud Storage without specifying the generation of the object, the new build will use the current object, which may be different from the original build source.
• If the original build pulled source from Cloud Storage and specified the generation of the object, the new build will attempt to use the same object, which may or may not be available depending on the bucket’s lifecycle management settings.

Long running operations

Calling poller() on the resulting builder returns an implementation of the lro::Poller trait. You need to call Poller::poll on this Poller at least once to start the LRO. You may periodically poll this object to find the status of the operation. The poller automatically extract the final response value and any intermediate metadata values.

Calling send() on the resulting builder starts a LRO (long-Running Operation). LROs run in the background, and the application may poll them periodically to find out if they have succeeded, or failed. See below for instructions on how to manually use the resulting Operation. We recommend poller() in favor of send().

Polling until completion

Applications that do not care about intermediate results in a long-running operation may use the until_done() function:

async fn wait(
    mut poller: impl lro::Poller<model::Build, model::BuildOperationMetadata>
) -> Result<model::Build> {
    poller.until_done().await
}

This will wait until the LRO completes (successfully or with an error). Applications can set the PollingPolicy and PollingBackoffPolicy to control for how long the function runs.

Polling with detailed metadata updates

Using the result of poller() follows a common pattern:

async fn wait(
    mut poller: impl lro::Poller<model::Build, model::BuildOperationMetadata>
) -> Result<model::Build> {
    while let Some(p) = poller.poll().await {
        match p {
            lro::PollingResult::Completed(r) => { return r; },
            lro::PollingResult::InProgress(m) => { println!("in progress {m:?}"); },
            lro::PollingResult::PollingError(_) => { /* ignored */ },
        }
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
    Err(gax::error::Error::other("LRO never completed"))
}

Manually polling long-running operations

If you call send(), you need to examine the contents of the resulting Operation to determine the result of the operation.

If the done field is true, the operation has completed. The result field contains the final response, this will be a crate::model::Build (as an Any), or the error (as a Status).

If the done field is false, the operation has not completed. The operation may also include a crate::model::BuildOperationMetadata value in the metadata field. This value would also be encoded as an Any. The metadata may include information about how much progress the LRO has made.

To find out if the operation has completed, use the get_operation method and repeat the steps outlined above.

Note that most errors on get_operation do not indicate that the long-running operation failed. Long-running operation failures return the error status in the result field.

pub fn approve_build(&self, name: impl Into<String>) -> ApproveBuild

Approves or rejects a pending build.

If approved, the returned LRO will be analogous to the LRO returned from a CreateBuild call.

If rejected, the returned LRO will be immediately done.

Long running operations

Calling poller() on the resulting builder returns an implementation of the lro::Poller trait. You need to call Poller::poll on this Poller at least once to start the LRO. You may periodically poll this object to find the status of the operation. The poller automatically extract the final response value and any intermediate metadata values.

Calling send() on the resulting builder starts a LRO (long-Running Operation). LROs run in the background, and the application may poll them periodically to find out if they have succeeded, or failed. See below for instructions on how to manually use the resulting Operation. We recommend poller() in favor of send().

Polling until completion

Applications that do not care about intermediate results in a long-running operation may use the until_done() function:

async fn wait(
    mut poller: impl lro::Poller<model::Build, model::BuildOperationMetadata>
) -> Result<model::Build> {
    poller.until_done().await
}

This will wait until the LRO completes (successfully or with an error). Applications can set the PollingPolicy and PollingBackoffPolicy to control for how long the function runs.

Polling with detailed metadata updates

Using the result of poller() follows a common pattern:

async fn wait(
    mut poller: impl lro::Poller<model::Build, model::BuildOperationMetadata>
) -> Result<model::Build> {
    while let Some(p) = poller.poll().await {
        match p {
            lro::PollingResult::Completed(r) => { return r; },
            lro::PollingResult::InProgress(m) => { println!("in progress {m:?}"); },
            lro::PollingResult::PollingError(_) => { /* ignored */ },
        }
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
    Err(gax::error::Error::other("LRO never completed"))
}

Manually polling long-running operations

If you call send(), you need to examine the contents of the resulting Operation to determine the result of the operation.

If the done field is true, the operation has completed. The result field contains the final response, this will be a crate::model::Build (as an Any), or the error (as a Status).

If the done field is false, the operation has not completed. The operation may also include a crate::model::BuildOperationMetadata value in the metadata field. This value would also be encoded as an Any. The metadata may include information about how much progress the LRO has made.

To find out if the operation has completed, use the get_operation method and repeat the steps outlined above.

Note that most errors on get_operation do not indicate that the long-running operation failed. Long-running operation failures return the error status in the result field.

pub fn create_build_trigger( &self, project_id: impl Into<String>, ) -> CreateBuildTrigger

Creates a new BuildTrigger.

This API is experimental.

pub fn get_build_trigger( &self, project_id: impl Into<String>, trigger_id: impl Into<String>, ) -> GetBuildTrigger

Returns information about a BuildTrigger.

This API is experimental.

pub fn list_build_triggers( &self, project_id: impl Into<String>, ) -> ListBuildTriggers

Lists existing BuildTriggers.

This API is experimental.

pub fn delete_build_trigger( &self, project_id: impl Into<String>, trigger_id: impl Into<String>, ) -> DeleteBuildTrigger

Deletes a BuildTrigger by its project ID and trigger ID.

This API is experimental.

pub fn update_build_trigger( &self, project_id: impl Into<String>, trigger_id: impl Into<String>, ) -> UpdateBuildTrigger

Updates a BuildTrigger by its project ID and trigger ID.

This API is experimental.

pub fn run_build_trigger( &self, project_id: impl Into<String>, trigger_id: impl Into<String>, ) -> RunBuildTrigger

Runs a BuildTrigger at a particular source revision.

To run a regional or global trigger, use the POST request that includes the location endpoint in the path (ex. v1/projects/{projectId}/locations/{region}/triggers/{triggerId}:run). The POST request that does not include the location endpoint in the path can only be used when running global triggers.

Long running operations

Calling poller() on the resulting builder returns an implementation of the lro::Poller trait. You need to call Poller::poll on this Poller at least once to start the LRO. You may periodically poll this object to find the status of the operation. The poller automatically extract the final response value and any intermediate metadata values.

Calling send() on the resulting builder starts a LRO (long-Running Operation). LROs run in the background, and the application may poll them periodically to find out if they have succeeded, or failed. See below for instructions on how to manually use the resulting Operation. We recommend poller() in favor of send().

Polling until completion

Applications that do not care about intermediate results in a long-running operation may use the until_done() function:

async fn wait(
    mut poller: impl lro::Poller<model::Build, model::BuildOperationMetadata>
) -> Result<model::Build> {
    poller.until_done().await
}

This will wait until the LRO completes (successfully or with an error). Applications can set the PollingPolicy and PollingBackoffPolicy to control for how long the function runs.

Polling with detailed metadata updates

Using the result of poller() follows a common pattern:

async fn wait(
    mut poller: impl lro::Poller<model::Build, model::BuildOperationMetadata>
) -> Result<model::Build> {
    while let Some(p) = poller.poll().await {
        match p {
            lro::PollingResult::Completed(r) => { return r; },
            lro::PollingResult::InProgress(m) => { println!("in progress {m:?}"); },
            lro::PollingResult::PollingError(_) => { /* ignored */ },
        }
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
    Err(gax::error::Error::other("LRO never completed"))
}

Manually polling long-running operations

If you call send(), you need to examine the contents of the resulting Operation to determine the result of the operation.

If the done field is true, the operation has completed. The result field contains the final response, this will be a crate::model::Build (as an Any), or the error (as a Status).

If the done field is false, the operation has not completed. The operation may also include a crate::model::BuildOperationMetadata value in the metadata field. This value would also be encoded as an Any. The metadata may include information about how much progress the LRO has made.

To find out if the operation has completed, use the get_operation method and repeat the steps outlined above.

Note that most errors on get_operation do not indicate that the long-running operation failed. Long-running operation failures return the error status in the result field.

pub fn receive_trigger_webhook( &self, project_id: impl Into<String>, trigger: impl Into<String>, ) -> ReceiveTriggerWebhook

ReceiveTriggerWebhook [Experimental] is called when the API receives a webhook request targeted at a specific trigger.

pub fn create_worker_pool(&self, parent: impl Into<String>) -> CreateWorkerPool

Creates a WorkerPool.

Long running operations

Calling poller() on the resulting builder returns an implementation of the lro::Poller trait. You need to call Poller::poll on this Poller at least once to start the LRO. You may periodically poll this object to find the status of the operation. The poller automatically extract the final response value and any intermediate metadata values.

Calling send() on the resulting builder starts a LRO (long-Running Operation). LROs run in the background, and the application may poll them periodically to find out if they have succeeded, or failed. See below for instructions on how to manually use the resulting Operation. We recommend poller() in favor of send().

Polling until completion

Applications that do not care about intermediate results in a long-running operation may use the until_done() function:

async fn wait(
    mut poller: impl lro::Poller<model::WorkerPool, model::CreateWorkerPoolOperationMetadata>
) -> Result<model::WorkerPool> {
    poller.until_done().await
}

This will wait until the LRO completes (successfully or with an error). Applications can set the PollingPolicy and PollingBackoffPolicy to control for how long the function runs.

Polling with detailed metadata updates

Using the result of poller() follows a common pattern:

async fn wait(
    mut poller: impl lro::Poller<model::WorkerPool, model::CreateWorkerPoolOperationMetadata>
) -> Result<model::WorkerPool> {
    while let Some(p) = poller.poll().await {
        match p {
            lro::PollingResult::Completed(r) => { return r; },
            lro::PollingResult::InProgress(m) => { println!("in progress {m:?}"); },
            lro::PollingResult::PollingError(_) => { /* ignored */ },
        }
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
    Err(gax::error::Error::other("LRO never completed"))
}

Manually polling long-running operations

If you call send(), you need to examine the contents of the resulting Operation to determine the result of the operation.

If the done field is true, the operation has completed. The result field contains the final response, this will be a crate::model::WorkerPool (as an Any), or the error (as a Status).

If the done field is false, the operation has not completed. The operation may also include a crate::model::CreateWorkerPoolOperationMetadata value in the metadata field. This value would also be encoded as an Any. The metadata may include information about how much progress the LRO has made.

To find out if the operation has completed, use the get_operation method and repeat the steps outlined above.

Note that most errors on get_operation do not indicate that the long-running operation failed. Long-running operation failures return the error status in the result field.

pub fn get_worker_pool(&self, name: impl Into<String>) -> GetWorkerPool

Returns details of a WorkerPool.

pub fn delete_worker_pool(&self, name: impl Into<String>) -> DeleteWorkerPool

Deletes a WorkerPool.

Long running operations

Calling poller() on the resulting builder returns an implementation of the lro::Poller trait. You need to call Poller::poll on this Poller at least once to start the LRO. You may periodically poll this object to find the status of the operation. The poller automatically extract the final response value and any intermediate metadata values.

Calling send() on the resulting builder starts a LRO (long-Running Operation). LROs run in the background, and the application may poll them periodically to find out if they have succeeded, or failed. See below for instructions on how to manually use the resulting Operation. We recommend poller() in favor of send().

Polling until completion

Applications that do not care about intermediate results in a long-running operation may use the until_done() function:

async fn wait(
    mut poller: impl lro::Poller<wkt::Empty, model::DeleteWorkerPoolOperationMetadata>
) -> Result<wkt::Empty> {
    poller.until_done().await
}

This will wait until the LRO completes (successfully or with an error). Applications can set the PollingPolicy and PollingBackoffPolicy to control for how long the function runs.

Polling with detailed metadata updates

Using the result of poller() follows a common pattern:

async fn wait(
    mut poller: impl lro::Poller<wkt::Empty, model::DeleteWorkerPoolOperationMetadata>
) -> Result<wkt::Empty> {
    while let Some(p) = poller.poll().await {
        match p {
            lro::PollingResult::Completed(r) => { return r; },
            lro::PollingResult::InProgress(m) => { println!("in progress {m:?}"); },
            lro::PollingResult::PollingError(_) => { /* ignored */ },
        }
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
    Err(gax::error::Error::other("LRO never completed"))
}

Manually polling long-running operations

If you call send(), you need to examine the contents of the resulting Operation to determine the result of the operation.

If the done field is true, the operation has completed. The result field contains the final response, this will be a wkt::Empty (as an Any), or the error (as a Status).

If the done field is false, the operation has not completed. The operation may also include a crate::model::DeleteWorkerPoolOperationMetadata value in the metadata field. This value would also be encoded as an Any. The metadata may include information about how much progress the LRO has made.

To find out if the operation has completed, use the get_operation method and repeat the steps outlined above.

Note that most errors on get_operation do not indicate that the long-running operation failed. Long-running operation failures return the error status in the result field.

pub fn update_worker_pool( &self, worker_pool: impl Into<WorkerPool>, ) -> UpdateWorkerPool

Updates a WorkerPool.

Long running operations

Calling poller() on the resulting builder returns an implementation of the lro::Poller trait. You need to call Poller::poll on this Poller at least once to start the LRO. You may periodically poll this object to find the status of the operation. The poller automatically extract the final response value and any intermediate metadata values.

Calling send() on the resulting builder starts a LRO (long-Running Operation). LROs run in the background, and the application may poll them periodically to find out if they have succeeded, or failed. See below for instructions on how to manually use the resulting Operation. We recommend poller() in favor of send().

Polling until completion

Applications that do not care about intermediate results in a long-running operation may use the until_done() function:

async fn wait(
    mut poller: impl lro::Poller<model::WorkerPool, model::UpdateWorkerPoolOperationMetadata>
) -> Result<model::WorkerPool> {
    poller.until_done().await
}

This will wait until the LRO completes (successfully or with an error). Applications can set the PollingPolicy and PollingBackoffPolicy to control for how long the function runs.

Polling with detailed metadata updates

Using the result of poller() follows a common pattern:

async fn wait(
    mut poller: impl lro::Poller<model::WorkerPool, model::UpdateWorkerPoolOperationMetadata>
) -> Result<model::WorkerPool> {
    while let Some(p) = poller.poll().await {
        match p {
            lro::PollingResult::Completed(r) => { return r; },
            lro::PollingResult::InProgress(m) => { println!("in progress {m:?}"); },
            lro::PollingResult::PollingError(_) => { /* ignored */ },
        }
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    }
    Err(gax::error::Error::other("LRO never completed"))
}

Manually polling long-running operations

If you call send(), you need to examine the contents of the resulting Operation to determine the result of the operation.

If the done field is true, the operation has completed. The result field contains the final response, this will be a crate::model::WorkerPool (as an Any), or the error (as a Status).

If the done field is false, the operation has not completed. The operation may also include a crate::model::UpdateWorkerPoolOperationMetadata value in the metadata field. This value would also be encoded as an Any. The metadata may include information about how much progress the LRO has made.

To find out if the operation has completed, use the get_operation method and repeat the steps outlined above.

Note that most errors on get_operation do not indicate that the long-running operation failed. Long-running operation failures return the error status in the result field.

pub fn list_worker_pools(&self, parent: impl Into<String>) -> ListWorkerPools

Lists WorkerPools.

pub fn get_operation(&self, name: impl Into<String>) -> GetOperation

Provides the Operations service functionality in this service.

pub fn cancel_operation(&self, name: impl Into<String>) -> CancelOperation

Provides the Operations service functionality in this service.

Trait Implementations

impl Clone for CloudBuild

fn clone(&self) -> CloudBuild

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for CloudBuild

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.