pub struct PutBucketLifecycleConfigurationFluentBuilder { /* private fields */ }
Expand description
Fluent builder constructing a request to PutBucketLifecycleConfiguration
.
Creates a new lifecycle configuration for the bucket or replaces an existing lifecycle configuration. Keep in mind that this will overwrite an existing lifecycle configuration, so if you want to retain any configuration details, they must be included in the new lifecycle configuration. For information about lifecycle configuration, see Managing your storage lifecycle.
- Rules
- Permissions
- HTTP Host header syntax
-
You specify the lifecycle configuration in your request body. The lifecycle configuration is specified as XML consisting of one or more rules. An Amazon S3 Lifecycle configuration can have up to 1,000 rules. This limit is not adjustable.
Bucket lifecycle configuration supports specifying a lifecycle rule using an object key name prefix, one or more object tags, object size, or any combination of these. Accordingly, this section describes the latest API. The previous version of the API supported filtering based only on an object key name prefix, which is supported for backward compatibility for general purpose buckets. For the related API description, see PutBucketLifecycle.
Lifecyle configurations for directory buckets only support expiring objects and cancelling multipart uploads. Expiring of versioned objects,transitions and tag filters are not supported.
A lifecycle rule consists of the following:
-
A filter identifying a subset of objects to which the rule applies. The filter can be based on a key name prefix, object tags, object size, or any combination of these.
-
A status indicating whether the rule is in effect.
-
One or more lifecycle transition and expiration actions that you want Amazon S3 to perform on the objects identified by the filter. If the state of your bucket is versioning-enabled or versioning-suspended, you can have many versions of the same object (one current version and zero or more noncurrent versions). Amazon S3 provides predefined actions that you can specify for current and noncurrent object versions.
For more information, see Object Lifecycle Management and Lifecycle Configuration Elements.
-
-
-
General purpose bucket permissions - By default, all Amazon S3 resources are private, including buckets, objects, and related subresources (for example, lifecycle configuration and website configuration). Only the resource owner (that is, the Amazon Web Services account that created it) can access the resource. The resource owner can optionally grant access permissions to others by writing an access policy. For this operation, a user must have the
s3:PutLifecycleConfiguration
permission.You can also explicitly deny permissions. An explicit deny also supersedes any other permissions. If you want to block users or accounts from removing or deleting objects from your bucket, you must deny them permissions for the following actions:
-
s3:DeleteObject
-
s3:DeleteObjectVersion
-
s3:PutLifecycleConfiguration
For more information about permissions, see Managing Access Permissions to Your Amazon S3 Resources.
-
-
Directory bucket permissions - You must have the
s3express:PutLifecycleConfiguration
permission in an IAM identity-based policy to use this operation. Cross-account access to this API operation isn't supported. The resource owner can optionally grant access permissions to others by creating a role or user for them as long as they are within the same account as the owner and resource.For more information about directory bucket policies and permissions, see Authorizing Regional endpoint APIs with IAM in the Amazon S3 User Guide.
Directory buckets - For directory buckets, you must make requests for this API operation to the Regional endpoint. These endpoints support path-style requests in the format
https://s3express-control.region_code.amazonaws.com/bucket-name
. Virtual-hosted-style requests aren't supported. For more information, see Regional and Zonal endpoints in the Amazon S3 User Guide.
-
-
Directory buckets - The HTTP Host header syntax is
s3express-control.region.amazonaws.com
.The following operations are related to
PutBucketLifecycleConfiguration
:
Implementations§
Source§impl PutBucketLifecycleConfigurationFluentBuilder
impl PutBucketLifecycleConfigurationFluentBuilder
Sourcepub fn as_input(&self) -> &PutBucketLifecycleConfigurationInputBuilder
pub fn as_input(&self) -> &PutBucketLifecycleConfigurationInputBuilder
Access the PutBucketLifecycleConfiguration as a reference.
Sourcepub async fn send(
self,
) -> Result<PutBucketLifecycleConfigurationOutput, SdkError<PutBucketLifecycleConfigurationError, HttpResponse>>
pub async fn send( self, ) -> Result<PutBucketLifecycleConfigurationOutput, SdkError<PutBucketLifecycleConfigurationError, HttpResponse>>
Sends the request and returns the response.
If an error occurs, an SdkError
will be returned with additional details that
can be matched against.
By default, any retryable failures will be retried twice. Retry behavior is configurable with the RetryConfig, which can be set when configuring the client.
Sourcepub fn customize(
self,
) -> CustomizableOperation<PutBucketLifecycleConfigurationOutput, PutBucketLifecycleConfigurationError, Self>
pub fn customize( self, ) -> CustomizableOperation<PutBucketLifecycleConfigurationOutput, PutBucketLifecycleConfigurationError, Self>
Consumes this builder, creating a customizable operation that can be modified before being sent.
Sourcepub fn bucket(self, input: impl Into<String>) -> Self
pub fn bucket(self, input: impl Into<String>) -> Self
The name of the bucket for which to set the configuration.
Sourcepub fn set_bucket(self, input: Option<String>) -> Self
pub fn set_bucket(self, input: Option<String>) -> Self
The name of the bucket for which to set the configuration.
Sourcepub fn get_bucket(&self) -> &Option<String>
pub fn get_bucket(&self) -> &Option<String>
The name of the bucket for which to set the configuration.
Sourcepub fn checksum_algorithm(self, input: ChecksumAlgorithm) -> Self
pub fn checksum_algorithm(self, input: ChecksumAlgorithm) -> Self
Indicates the algorithm used to create the checksum for the object when you use the SDK. This header will not provide any additional functionality if you don't use the SDK. When you send this header, there must be a corresponding x-amz-checksum
or x-amz-trailer
header sent. Otherwise, Amazon S3 fails the request with the HTTP status code 400 Bad Request
. For more information, see Checking object integrity in the Amazon S3 User Guide.
If you provide an individual checksum, Amazon S3 ignores any provided ChecksumAlgorithm
parameter.
Sourcepub fn set_checksum_algorithm(self, input: Option<ChecksumAlgorithm>) -> Self
pub fn set_checksum_algorithm(self, input: Option<ChecksumAlgorithm>) -> Self
Indicates the algorithm used to create the checksum for the object when you use the SDK. This header will not provide any additional functionality if you don't use the SDK. When you send this header, there must be a corresponding x-amz-checksum
or x-amz-trailer
header sent. Otherwise, Amazon S3 fails the request with the HTTP status code 400 Bad Request
. For more information, see Checking object integrity in the Amazon S3 User Guide.
If you provide an individual checksum, Amazon S3 ignores any provided ChecksumAlgorithm
parameter.
Sourcepub fn get_checksum_algorithm(&self) -> &Option<ChecksumAlgorithm>
pub fn get_checksum_algorithm(&self) -> &Option<ChecksumAlgorithm>
Indicates the algorithm used to create the checksum for the object when you use the SDK. This header will not provide any additional functionality if you don't use the SDK. When you send this header, there must be a corresponding x-amz-checksum
or x-amz-trailer
header sent. Otherwise, Amazon S3 fails the request with the HTTP status code 400 Bad Request
. For more information, see Checking object integrity in the Amazon S3 User Guide.
If you provide an individual checksum, Amazon S3 ignores any provided ChecksumAlgorithm
parameter.
Sourcepub fn lifecycle_configuration(
self,
input: BucketLifecycleConfiguration,
) -> Self
pub fn lifecycle_configuration( self, input: BucketLifecycleConfiguration, ) -> Self
Container for lifecycle rules. You can add as many as 1,000 rules.
Sourcepub fn set_lifecycle_configuration(
self,
input: Option<BucketLifecycleConfiguration>,
) -> Self
pub fn set_lifecycle_configuration( self, input: Option<BucketLifecycleConfiguration>, ) -> Self
Container for lifecycle rules. You can add as many as 1,000 rules.
Sourcepub fn get_lifecycle_configuration(
&self,
) -> &Option<BucketLifecycleConfiguration>
pub fn get_lifecycle_configuration( &self, ) -> &Option<BucketLifecycleConfiguration>
Container for lifecycle rules. You can add as many as 1,000 rules.
Sourcepub fn expected_bucket_owner(self, input: impl Into<String>) -> Self
pub fn expected_bucket_owner(self, input: impl Into<String>) -> Self
The account ID of the expected bucket owner. If the account ID that you provide does not match the actual owner of the bucket, the request fails with the HTTP status code 403 Forbidden
(access denied).
This parameter applies to general purpose buckets only. It is not supported for directory bucket lifecycle configurations.
Sourcepub fn set_expected_bucket_owner(self, input: Option<String>) -> Self
pub fn set_expected_bucket_owner(self, input: Option<String>) -> Self
The account ID of the expected bucket owner. If the account ID that you provide does not match the actual owner of the bucket, the request fails with the HTTP status code 403 Forbidden
(access denied).
This parameter applies to general purpose buckets only. It is not supported for directory bucket lifecycle configurations.
Sourcepub fn get_expected_bucket_owner(&self) -> &Option<String>
pub fn get_expected_bucket_owner(&self) -> &Option<String>
The account ID of the expected bucket owner. If the account ID that you provide does not match the actual owner of the bucket, the request fails with the HTTP status code 403 Forbidden
(access denied).
This parameter applies to general purpose buckets only. It is not supported for directory bucket lifecycle configurations.
Sourcepub fn transition_default_minimum_object_size(
self,
input: TransitionDefaultMinimumObjectSize,
) -> Self
pub fn transition_default_minimum_object_size( self, input: TransitionDefaultMinimumObjectSize, ) -> Self
Indicates which default minimum object size behavior is applied to the lifecycle configuration.
This parameter applies to general purpose buckets only. It is not supported for directory bucket lifecycle configurations.
-
all_storage_classes_128K
- Objects smaller than 128 KB will not transition to any storage class by default. -
varies_by_storage_class
- Objects smaller than 128 KB will transition to Glacier Flexible Retrieval or Glacier Deep Archive storage classes. By default, all other storage classes will prevent transitions smaller than 128 KB.
To customize the minimum object size for any transition you can add a filter that specifies a custom ObjectSizeGreaterThan
or ObjectSizeLessThan
in the body of your transition rule. Custom filters always take precedence over the default transition behavior.
Sourcepub fn set_transition_default_minimum_object_size(
self,
input: Option<TransitionDefaultMinimumObjectSize>,
) -> Self
pub fn set_transition_default_minimum_object_size( self, input: Option<TransitionDefaultMinimumObjectSize>, ) -> Self
Indicates which default minimum object size behavior is applied to the lifecycle configuration.
This parameter applies to general purpose buckets only. It is not supported for directory bucket lifecycle configurations.
-
all_storage_classes_128K
- Objects smaller than 128 KB will not transition to any storage class by default. -
varies_by_storage_class
- Objects smaller than 128 KB will transition to Glacier Flexible Retrieval or Glacier Deep Archive storage classes. By default, all other storage classes will prevent transitions smaller than 128 KB.
To customize the minimum object size for any transition you can add a filter that specifies a custom ObjectSizeGreaterThan
or ObjectSizeLessThan
in the body of your transition rule. Custom filters always take precedence over the default transition behavior.
Sourcepub fn get_transition_default_minimum_object_size(
&self,
) -> &Option<TransitionDefaultMinimumObjectSize>
pub fn get_transition_default_minimum_object_size( &self, ) -> &Option<TransitionDefaultMinimumObjectSize>
Indicates which default minimum object size behavior is applied to the lifecycle configuration.
This parameter applies to general purpose buckets only. It is not supported for directory bucket lifecycle configurations.
-
all_storage_classes_128K
- Objects smaller than 128 KB will not transition to any storage class by default. -
varies_by_storage_class
- Objects smaller than 128 KB will transition to Glacier Flexible Retrieval or Glacier Deep Archive storage classes. By default, all other storage classes will prevent transitions smaller than 128 KB.
To customize the minimum object size for any transition you can add a filter that specifies a custom ObjectSizeGreaterThan
or ObjectSizeLessThan
in the body of your transition rule. Custom filters always take precedence over the default transition behavior.
Trait Implementations§
Source§impl Clone for PutBucketLifecycleConfigurationFluentBuilder
impl Clone for PutBucketLifecycleConfigurationFluentBuilder
Source§fn clone(&self) -> PutBucketLifecycleConfigurationFluentBuilder
fn clone(&self) -> PutBucketLifecycleConfigurationFluentBuilder
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moreAuto Trait Implementations§
impl Freeze for PutBucketLifecycleConfigurationFluentBuilder
impl !RefUnwindSafe for PutBucketLifecycleConfigurationFluentBuilder
impl Send for PutBucketLifecycleConfigurationFluentBuilder
impl Sync for PutBucketLifecycleConfigurationFluentBuilder
impl Unpin for PutBucketLifecycleConfigurationFluentBuilder
impl !UnwindSafe for PutBucketLifecycleConfigurationFluentBuilder
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>
Returns self
with the
fg()
set to
Color::BrightBlack
.
§Example
println!("{}", value.bright_black());
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>
Returns self
with the
fg()
set to
Color::BrightGreen
.
§Example
println!("{}", value.bright_green());
Source§fn bright_yellow(&self) -> Painted<&T>
fn bright_yellow(&self) -> Painted<&T>
Returns self
with the
fg()
set to
Color::BrightYellow
.
§Example
println!("{}", value.bright_yellow());
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>
Returns self
with the
fg()
set to
Color::BrightMagenta
.
§Example
println!("{}", value.bright_magenta());
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>
Returns self
with the
fg()
set to
Color::BrightWhite
.
§Example
println!("{}", value.bright_white());
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>
Returns self
with the
bg()
set to
Color::BrightBlack
.
§Example
println!("{}", value.on_bright_black());
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>
Returns self
with the
bg()
set to
Color::BrightGreen
.
§Example
println!("{}", value.on_bright_green());
Source§fn on_bright_yellow(&self) -> Painted<&T>
fn on_bright_yellow(&self) -> Painted<&T>
Returns self
with the
bg()
set to
Color::BrightYellow
.
§Example
println!("{}", value.on_bright_yellow());
Source§fn on_bright_blue(&self) -> Painted<&T>
fn on_bright_blue(&self) -> Painted<&T>
Returns self
with the
bg()
set to
Color::BrightBlue
.
§Example
println!("{}", value.on_bright_blue());
Source§fn on_bright_magenta(&self) -> Painted<&T>
fn on_bright_magenta(&self) -> Painted<&T>
Returns self
with the
bg()
set to
Color::BrightMagenta
.
§Example
println!("{}", value.on_bright_magenta());
Source§fn on_bright_cyan(&self) -> Painted<&T>
fn on_bright_cyan(&self) -> Painted<&T>
Returns self
with the
bg()
set to
Color::BrightCyan
.
§Example
println!("{}", value.on_bright_cyan());
Source§fn on_bright_white(&self) -> Painted<&T>
fn on_bright_white(&self) -> Painted<&T>
Returns self
with the
bg()
set to
Color::BrightWhite
.
§Example
println!("{}", value.on_bright_white());
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 underline(&self) -> Painted<&T>
fn underline(&self) -> Painted<&T>
Returns self
with the
attr()
set to
Attribute::Underline
.
§Example
println!("{}", value.underline());
Source§fn rapid_blink(&self) -> Painted<&T>
fn rapid_blink(&self) -> Painted<&T>
Returns self
with the
attr()
set to
Attribute::RapidBlink
.
§Example
println!("{}", value.rapid_blink());
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);