#[non_exhaustive]pub struct ServiceDeployment {Show 17 fields
pub service_deployment_arn: Option<String>,
pub service_arn: Option<String>,
pub cluster_arn: Option<String>,
pub created_at: Option<DateTime>,
pub started_at: Option<DateTime>,
pub finished_at: Option<DateTime>,
pub stopped_at: Option<DateTime>,
pub updated_at: Option<DateTime>,
pub source_service_revisions: Option<Vec<ServiceRevisionSummary>>,
pub target_service_revision: Option<ServiceRevisionSummary>,
pub status: Option<ServiceDeploymentStatus>,
pub status_reason: Option<String>,
pub lifecycle_stage: Option<ServiceDeploymentLifecycleStage>,
pub deployment_configuration: Option<DeploymentConfiguration>,
pub rollback: Option<Rollback>,
pub deployment_circuit_breaker: Option<ServiceDeploymentCircuitBreaker>,
pub alarms: Option<ServiceDeploymentAlarms>,
}Expand description
Information about the service deployment.
Service deployments provide a comprehensive view of your deployments. For information about service deployments, see View service history using Amazon ECS service deployments in the Amazon Elastic Container Service Developer Guide .
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.service_deployment_arn: Option<String>The ARN of the service deployment.
service_arn: Option<String>The ARN of the service for this service deployment.
cluster_arn: Option<String>The ARN of the cluster that hosts the service.
created_at: Option<DateTime>The time the service deployment was created. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
started_at: Option<DateTime>The time the service deployment statred. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
finished_at: Option<DateTime>The time the service deployment finished. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
stopped_at: Option<DateTime>The time the service deployment stopped. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
The service deployment stops when any of the following actions happen:
-
A user manually stops the deployment
-
The rollback option is not in use for the failure detection mechanism (the circuit breaker or alarm-based) and the service fails.
updated_at: Option<DateTime>The time that the service deployment was last updated. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
source_service_revisions: Option<Vec<ServiceRevisionSummary>>The currently deployed workload configuration.
target_service_revision: Option<ServiceRevisionSummary>The workload configuration being deployed.
status: Option<ServiceDeploymentStatus>The service deployment state.
status_reason: Option<String>Information about why the service deployment is in the current status. For example, the circuit breaker detected a failure.
lifecycle_stage: Option<ServiceDeploymentLifecycleStage>The current lifecycle stage of the deployment. Possible values include:
-
RECONCILE_SERVICE
The reconciliation stage that only happens when you start a new service deployment with more than 1 service revision in an ACTIVE state.
-
PRE_SCALE_UP
The green service revision has not started. The blue service revision is handling 100% of the production traffic. There is no test traffic.
-
SCALE_UP
The stage when the green service revision scales up to 100% and launches new tasks. The green service revision is not serving any traffic at this point.
-
POST_SCALE_UP
The green service revision has started. The blue service revision is handling 100% of the production traffic. There is no test traffic.
-
TEST_TRAFFIC_SHIFT
The blue and green service revisions are running. The blue service revision handles 100% of the production traffic. The green service revision is migrating from 0% to 100% of test traffic.
-
POST_TEST_TRAFFIC_SHIFT
The test traffic shift is complete. The green service revision handles 100% of the test traffic.
-
PRODUCTION_TRAFFIC_SHIFT
Production traffic is shifting to the green service revision. The green service revision is migrating from 0% to 100% of production traffic.
-
POST_PRODUCTION_TRAFFIC_SHIFT
The production traffic shift is complete.
-
BAKE_TIME
The stage when both blue and green service revisions are running simultaneously after the production traffic has shifted.
-
CLEAN_UP
The stage when the blue service revision has completely scaled down to 0 running tasks. The green service revision is now the production service revision after this stage.
deployment_configuration: Option<DeploymentConfiguration>Optional deployment parameters that control how many tasks run during a deployment and the ordering of stopping and starting tasks.
rollback: Option<Rollback>The rollback options the service deployment uses when the deployment fails.
deployment_circuit_breaker: Option<ServiceDeploymentCircuitBreaker>The circuit breaker configuration that determines a service deployment failed.
alarms: Option<ServiceDeploymentAlarms>The CloudWatch alarms that determine when a service deployment fails.
Implementations§
Source§impl ServiceDeployment
impl ServiceDeployment
Sourcepub fn service_deployment_arn(&self) -> Option<&str>
pub fn service_deployment_arn(&self) -> Option<&str>
The ARN of the service deployment.
Sourcepub fn service_arn(&self) -> Option<&str>
pub fn service_arn(&self) -> Option<&str>
The ARN of the service for this service deployment.
Sourcepub fn cluster_arn(&self) -> Option<&str>
pub fn cluster_arn(&self) -> Option<&str>
The ARN of the cluster that hosts the service.
Sourcepub fn created_at(&self) -> Option<&DateTime>
pub fn created_at(&self) -> Option<&DateTime>
The time the service deployment was created. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
Sourcepub fn started_at(&self) -> Option<&DateTime>
pub fn started_at(&self) -> Option<&DateTime>
The time the service deployment statred. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
Sourcepub fn finished_at(&self) -> Option<&DateTime>
pub fn finished_at(&self) -> Option<&DateTime>
The time the service deployment finished. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
Sourcepub fn stopped_at(&self) -> Option<&DateTime>
pub fn stopped_at(&self) -> Option<&DateTime>
The time the service deployment stopped. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
The service deployment stops when any of the following actions happen:
-
A user manually stops the deployment
-
The rollback option is not in use for the failure detection mechanism (the circuit breaker or alarm-based) and the service fails.
Sourcepub fn updated_at(&self) -> Option<&DateTime>
pub fn updated_at(&self) -> Option<&DateTime>
The time that the service deployment was last updated. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
Sourcepub fn source_service_revisions(&self) -> &[ServiceRevisionSummary]
pub fn source_service_revisions(&self) -> &[ServiceRevisionSummary]
The currently deployed workload configuration.
If no value was sent for this field, a default will be set. If you want to determine if no value was sent, use .source_service_revisions.is_none().
Sourcepub fn target_service_revision(&self) -> Option<&ServiceRevisionSummary>
pub fn target_service_revision(&self) -> Option<&ServiceRevisionSummary>
The workload configuration being deployed.
Sourcepub fn status(&self) -> Option<&ServiceDeploymentStatus>
pub fn status(&self) -> Option<&ServiceDeploymentStatus>
The service deployment state.
Sourcepub fn status_reason(&self) -> Option<&str>
pub fn status_reason(&self) -> Option<&str>
Information about why the service deployment is in the current status. For example, the circuit breaker detected a failure.
Sourcepub fn lifecycle_stage(&self) -> Option<&ServiceDeploymentLifecycleStage>
pub fn lifecycle_stage(&self) -> Option<&ServiceDeploymentLifecycleStage>
The current lifecycle stage of the deployment. Possible values include:
-
RECONCILE_SERVICE
The reconciliation stage that only happens when you start a new service deployment with more than 1 service revision in an ACTIVE state.
-
PRE_SCALE_UP
The green service revision has not started. The blue service revision is handling 100% of the production traffic. There is no test traffic.
-
SCALE_UP
The stage when the green service revision scales up to 100% and launches new tasks. The green service revision is not serving any traffic at this point.
-
POST_SCALE_UP
The green service revision has started. The blue service revision is handling 100% of the production traffic. There is no test traffic.
-
TEST_TRAFFIC_SHIFT
The blue and green service revisions are running. The blue service revision handles 100% of the production traffic. The green service revision is migrating from 0% to 100% of test traffic.
-
POST_TEST_TRAFFIC_SHIFT
The test traffic shift is complete. The green service revision handles 100% of the test traffic.
-
PRODUCTION_TRAFFIC_SHIFT
Production traffic is shifting to the green service revision. The green service revision is migrating from 0% to 100% of production traffic.
-
POST_PRODUCTION_TRAFFIC_SHIFT
The production traffic shift is complete.
-
BAKE_TIME
The stage when both blue and green service revisions are running simultaneously after the production traffic has shifted.
-
CLEAN_UP
The stage when the blue service revision has completely scaled down to 0 running tasks. The green service revision is now the production service revision after this stage.
Sourcepub fn deployment_configuration(&self) -> Option<&DeploymentConfiguration>
pub fn deployment_configuration(&self) -> Option<&DeploymentConfiguration>
Optional deployment parameters that control how many tasks run during a deployment and the ordering of stopping and starting tasks.
Sourcepub fn rollback(&self) -> Option<&Rollback>
pub fn rollback(&self) -> Option<&Rollback>
The rollback options the service deployment uses when the deployment fails.
Sourcepub fn deployment_circuit_breaker(
&self,
) -> Option<&ServiceDeploymentCircuitBreaker>
pub fn deployment_circuit_breaker( &self, ) -> Option<&ServiceDeploymentCircuitBreaker>
The circuit breaker configuration that determines a service deployment failed.
Sourcepub fn alarms(&self) -> Option<&ServiceDeploymentAlarms>
pub fn alarms(&self) -> Option<&ServiceDeploymentAlarms>
The CloudWatch alarms that determine when a service deployment fails.
Source§impl ServiceDeployment
impl ServiceDeployment
Sourcepub fn builder() -> ServiceDeploymentBuilder
pub fn builder() -> ServiceDeploymentBuilder
Creates a new builder-style object to manufacture ServiceDeployment.
Trait Implementations§
Source§impl Clone for ServiceDeployment
impl Clone for ServiceDeployment
Source§fn clone(&self) -> ServiceDeployment
fn clone(&self) -> ServiceDeployment
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read moreSource§impl Debug for ServiceDeployment
impl Debug for ServiceDeployment
Source§impl PartialEq for ServiceDeployment
impl PartialEq for ServiceDeployment
impl StructuralPartialEq for ServiceDeployment
Auto Trait Implementations§
impl Freeze for ServiceDeployment
impl RefUnwindSafe for ServiceDeployment
impl Send for ServiceDeployment
impl Sync for ServiceDeployment
impl Unpin for ServiceDeployment
impl UnwindSafe for ServiceDeployment
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§impl<T> Instrument for T
impl<T> Instrument for T
Source§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
Source§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
Source§impl<T> IntoEither for T
impl<T> IntoEither for T
Source§fn into_either(self, into_left: bool) -> Either<Self, Self>
fn into_either(self, into_left: bool) -> Either<Self, Self>
self into a Left variant of Either<Self, Self>
if into_left is true.
Converts self into a Right variant of Either<Self, Self>
otherwise. Read moreSource§fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
self into a Left variant of Either<Self, Self>
if into_left(&self) returns true.
Converts self into a Right variant of Either<Self, Self>
otherwise. Read moreSource§impl<T> Paint for Twhere
T: ?Sized,
impl<T> Paint for Twhere
T: ?Sized,
Source§fn fg(&self, value: Color) -> Painted<&T>
fn fg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self with the foreground set to
value.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like red() and
green(), which have the same functionality but are
pithier.
§Example
Set foreground color to white using fg():
use yansi::{Paint, Color};
painted.fg(Color::White);Set foreground color to white using white().
use yansi::Paint;
painted.white();Source§fn bright_black(&self) -> Painted<&T>
fn bright_black(&self) -> Painted<&T>
Source§fn bright_red(&self) -> Painted<&T>
fn bright_red(&self) -> Painted<&T>
Source§fn bright_green(&self) -> Painted<&T>
fn bright_green(&self) -> Painted<&T>
Source§fn bright_yellow(&self) -> Painted<&T>
fn bright_yellow(&self) -> Painted<&T>
Source§fn bright_blue(&self) -> Painted<&T>
fn bright_blue(&self) -> Painted<&T>
Source§fn bright_magenta(&self) -> Painted<&T>
fn bright_magenta(&self) -> Painted<&T>
Source§fn bright_cyan(&self) -> Painted<&T>
fn bright_cyan(&self) -> Painted<&T>
Source§fn bright_white(&self) -> Painted<&T>
fn bright_white(&self) -> Painted<&T>
Source§fn bg(&self, value: Color) -> Painted<&T>
fn bg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self with the background set to
value.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like on_red() and
on_green(), which have the same functionality but
are pithier.
§Example
Set background color to red using fg():
use yansi::{Paint, Color};
painted.bg(Color::Red);Set background color to red using on_red().
use yansi::Paint;
painted.on_red();Source§fn on_primary(&self) -> Painted<&T>
fn on_primary(&self) -> Painted<&T>
Source§fn on_magenta(&self) -> Painted<&T>
fn on_magenta(&self) -> Painted<&T>
Source§fn on_bright_black(&self) -> Painted<&T>
fn on_bright_black(&self) -> Painted<&T>
Source§fn on_bright_red(&self) -> Painted<&T>
fn on_bright_red(&self) -> Painted<&T>
Source§fn on_bright_green(&self) -> Painted<&T>
fn on_bright_green(&self) -> Painted<&T>
Source§fn on_bright_yellow(&self) -> Painted<&T>
fn on_bright_yellow(&self) -> Painted<&T>
Source§fn on_bright_blue(&self) -> Painted<&T>
fn on_bright_blue(&self) -> Painted<&T>
Source§fn on_bright_magenta(&self) -> Painted<&T>
fn on_bright_magenta(&self) -> Painted<&T>
Source§fn on_bright_cyan(&self) -> Painted<&T>
fn on_bright_cyan(&self) -> Painted<&T>
Source§fn on_bright_white(&self) -> Painted<&T>
fn on_bright_white(&self) -> Painted<&T>
Source§fn attr(&self, value: Attribute) -> Painted<&T>
fn attr(&self, value: Attribute) -> Painted<&T>
Enables the styling Attribute value.
This method should be used rarely. Instead, prefer to use
attribute-specific builder methods like bold() and
underline(), which have the same functionality
but are pithier.
§Example
Make text bold using attr():
use yansi::{Paint, Attribute};
painted.attr(Attribute::Bold);Make text bold using using bold().
use yansi::Paint;
painted.bold();Source§fn rapid_blink(&self) -> Painted<&T>
fn rapid_blink(&self) -> Painted<&T>
Source§fn quirk(&self, value: Quirk) -> Painted<&T>
fn quirk(&self, value: Quirk) -> Painted<&T>
Enables the yansi Quirk value.
This method should be used rarely. Instead, prefer to use quirk-specific
builder methods like mask() and
wrap(), which have the same functionality but are
pithier.
§Example
Enable wrapping using .quirk():
use yansi::{Paint, Quirk};
painted.quirk(Quirk::Wrap);Enable wrapping using wrap().
use yansi::Paint;
painted.wrap();Source§fn clear(&self) -> Painted<&T>
👎Deprecated since 1.0.1: renamed to resetting() due to conflicts with Vec::clear().
The clear() method will be removed in a future release.
fn clear(&self) -> Painted<&T>
resetting() due to conflicts with Vec::clear().
The clear() method will be removed in a future release.Source§fn whenever(&self, value: Condition) -> Painted<&T>
fn whenever(&self, value: Condition) -> Painted<&T>
Conditionally enable styling based on whether the Condition value
applies. Replaces any previous condition.
See the crate level docs for more details.
§Example
Enable styling painted only when both stdout and stderr are TTYs:
use yansi::{Paint, Condition};
painted.red().on_yellow().whenever(Condition::STDOUTERR_ARE_TTY);