Struct Projects

Source

pub struct Projects { /* private fields */ }

Expand description

Implements a client for the Cloud Resource Manager API.

§Service Description

Manages Google Cloud Projects.

§Configuration

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

§Pooling and Cloning

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

Implementations§

Source §

impl Projects

Source

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

Creates a new client with the default configuration.

Source

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

Creates a new client with the specified configuration.

Source

pub fn from_stub<T>(stub: T) -> Self
where T: Projects + 'static,

Creates a new client from the provided stub.

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

Source

pub fn get_project(&self, name: impl Into<String>) -> GetProject

Retrieves the project identified by the specified name (for example, projects/415104041262).

The caller must have resourcemanager.projects.get permission for this project.

Source

pub fn list_projects(&self) -> ListProjects

Lists projects that are direct children of the specified folder or organization resource. list() provides a strongly consistent view of the projects underneath the specified parent resource. list() returns projects sorted based upon the (ascending) lexical ordering of their display_name. The caller must have resourcemanager.projects.list permission on the identified parent.

Source

pub fn search_projects(&self) -> SearchProjects

Search for projects that the caller has both resourcemanager.projects.get permission on, and also satisfy the specified query.

This method returns projects in an unspecified order.

This method is eventually consistent with project mutations; this means that a newly created project may not appear in the results or recent updates to an existing project may not be reflected in the results. To retrieve the latest state of a project, use the GetProject method.

Source

pub fn create_project(&self) -> CreateProject

Request that a new project be created. The result is an Operation which can be used to track the creation process. This process usually takes a few seconds, but can sometimes take much longer. The tracking Operation is automatically deleted after a few hours, so there is no need to call DeleteOperation.

§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::Project, model::CreateProjectMetadata>
) -> Result<model::Project> {
    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::Project, model::CreateProjectMetadata>
) -> Result<model::Project> {
    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::Project (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::CreateProjectMetadata 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.

Source

pub fn update_project(&self, project: impl Into<Project>) -> UpdateProject

Updates the display_name and labels of the project identified by the specified name (for example, projects/415104041262). Deleting all labels requires an update mask for labels field.

The caller must have resourcemanager.projects.update permission for this project.

§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::Project, model::UpdateProjectMetadata>
) -> Result<model::Project> {
    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::Project, model::UpdateProjectMetadata>
) -> Result<model::Project> {
    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::Project (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::UpdateProjectMetadata 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.

Source

pub fn move_project(&self, name: impl Into<String>) -> MoveProject

Move a project to another place in your resource hierarchy, under a new resource parent.

Returns an operation which can be used to track the process of the project move workflow. Upon success, the Operation.response field will be populated with the moved project.

The caller must have resourcemanager.projects.move permission on the project, on the project’s current and proposed new parent.

If project has no current parent, or it currently does not have an associated organization resource, you will also need the resourcemanager.projects.setIamPolicy permission in the project.

§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::Project, model::MoveProjectMetadata>
) -> Result<model::Project> {
    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::Project, model::MoveProjectMetadata>
) -> Result<model::Project> {
    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::Project (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::MoveProjectMetadata 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.

Source

pub fn delete_project(&self, name: impl Into<String>) -> DeleteProject

Marks the project identified by the specified name (for example, projects/415104041262) for deletion.

This method will only affect the project if it has a lifecycle state of ACTIVE.

This method changes the Project’s lifecycle state from ACTIVE to DELETE_REQUESTED. The deletion starts at an unspecified time, at which point the Project is no longer accessible.

Until the deletion completes, you can check the lifecycle state checked by retrieving the project with [GetProject] [google.cloud.resourcemanager.v3.Projects.GetProject], and the project remains visible to [ListProjects] [google.cloud.resourcemanager.v3.Projects.ListProjects]. However, you cannot update the project.

After the deletion completes, the project is not retrievable by the [GetProject] [google.cloud.resourcemanager.v3.Projects.GetProject], [ListProjects] [google.cloud.resourcemanager.v3.Projects.ListProjects], and SearchProjects methods.

This method behaves idempotently, such that deleting a DELETE_REQUESTED project will not cause an error, but also won’t do anything.

The caller must have resourcemanager.projects.delete permissions for this project.

§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::Project, model::DeleteProjectMetadata>
) -> Result<model::Project> {
    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::Project, model::DeleteProjectMetadata>
) -> Result<model::Project> {
    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::Project (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::DeleteProjectMetadata 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.

Source

pub fn undelete_project(&self, name: impl Into<String>) -> UndeleteProject

Restores the project identified by the specified name (for example, projects/415104041262). You can only use this method for a project that has a lifecycle state of [DELETE_REQUESTED] [Projects.State.DELETE_REQUESTED]. After deletion starts, the project cannot be restored.

The caller must have resourcemanager.projects.undelete permission for this project.

§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::Project, model::UndeleteProjectMetadata>
) -> Result<model::Project> {
    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::Project, model::UndeleteProjectMetadata>
) -> Result<model::Project> {
    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::Project (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::UndeleteProjectMetadata 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.

Source

pub fn get_iam_policy(&self, resource: impl Into<String>) -> GetIamPolicy

Returns the IAM access control policy for the specified project, in the format projects/{ProjectIdOrNumber} e.g. projects/123. Permission is denied if the policy or the resource do not exist.

Source

pub fn set_iam_policy(&self, resource: impl Into<String>) -> SetIamPolicy

Sets the IAM access control policy for the specified project, in the format projects/{ProjectIdOrNumber} e.g. projects/123.

CAUTION: This method will replace the existing policy, and cannot be used to append additional IAM settings.

Note: Removing service accounts from policies or changing their roles can render services completely inoperable. It is important to understand how the service account is being used before removing or updating its roles.

The following constraints apply when using setIamPolicy():

Project does not support allUsers and allAuthenticatedUsers as members in a Binding of a Policy.
The owner role can be granted to a user, serviceAccount, or a group that is part of an organization. For example, group@myownpersonaldomain.com could be added as an owner to a project in the myownpersonaldomain.com organization, but not the examplepetstore.com organization.
Service accounts can be made owners of a project directly without any restrictions. However, to be added as an owner, a user must be invited using the Cloud Platform console and must accept the invitation.
A user cannot be granted the owner role using setIamPolicy(). The user must be granted the owner role using the Cloud Platform Console and must explicitly accept the invitation.
Invitations to grant the owner role cannot be sent using setIamPolicy(); they must be sent only using the Cloud Platform Console.
If the project is not part of an organization, there must be at least one owner who has accepted the Terms of Service (ToS) agreement in the policy. Calling setIamPolicy() to remove the last ToS-accepted owner from the policy will fail. This restriction also applies to legacy projects that no longer have owners who have accepted the ToS. Edits to IAM policies will be rejected until the lack of a ToS-accepting owner is rectified. If the project is part of an organization, you can remove all owners, potentially making the organization inaccessible.