Rollout
Creates a new Rollout in a given project and location. Auto-naming is currently not supported for this resource. Note - this resource's API doesn't support deletion. When deleted, the resource will persist on Google Cloud even though it will be deleted from Pulumi state.
Properties
User annotations. These attributes can only be set and used by the user, and not by Google Cloud Deploy. See https://google.aip.dev/128#annotations for more details such as format and size limitations.
Approval state of the Rollout
.
Time at which the Rollout
was approved.
Name of the ControllerRollout
. Format is projects/{project}/ locations/{location}/deliveryPipelines/{deliveryPipeline}/ releases/{release}/rollouts/a-z{0,62}.
Time at which the Rollout
was created.
Time at which the Rollout
finished deploying.
The reason this rollout failed. This will always be unspecified while the rollout is in progress.
The resource name of the Cloud Build Build
object that is used to deploy the Rollout. Format is projects/{project}/locations/{location}/builds/{build}
.
Time at which the Rollout
started deploying.
Description of the Rollout
for user purposes. Max length is 255 characters.
Time at which the Rollout
was enqueued.
Additional information about the rollout failure, if available.
Labels are attributes that can be set and used by both the user and by Google Cloud Deploy. Labels must meet the following constraints: * Keys and values can contain only lowercase letters, numeric characters, underscores, and dashes. * All characters must use UTF-8 encoding, and international characters are allowed. * Keys must start with a lowercase letter or international character. * Each resource is limited to a maximum of 64 labels. Both keys and values are additionally constrained to be <= 128 bytes.
Metadata contains information about the rollout.
The phases that represent the workflows of this Rollout
.
Optional. A request ID to identify requests. Specify a unique request ID so that if you must retry your request, the server will know to ignore the request if it has already been completed. The server will guarantee that for at least 60 minutes since the first request. For example, consider a situation where you make an initial request and the request times out. If you make the request again with the same request ID, the server can check if original operation with the same request ID was received, and if so, will ignore the second request. This prevents clients from accidentally creating duplicate commitments. The request ID must be a valid UUID with the exception that zero UUID is not supported (00000000-0000-0000-0000-000000000000).
Optional. The starting phase ID for the Rollout
. If empty the Rollout
will start at the first phase.