Skip to main content

aws_sdk_codedeploy/
lib.rs

1#![allow(deprecated)]
2#![allow(unknown_lints)]
3#![allow(clippy::module_inception)]
4#![allow(clippy::upper_case_acronyms)]
5#![allow(clippy::large_enum_variant)]
6#![allow(clippy::wrong_self_convention)]
7#![allow(clippy::should_implement_trait)]
8#![allow(clippy::disallowed_names)]
9#![allow(clippy::vec_init_then_push)]
10#![allow(clippy::type_complexity)]
11#![allow(clippy::needless_return)]
12#![allow(clippy::derive_partial_eq_without_eq)]
13#![allow(clippy::result_large_err)]
14#![allow(clippy::unnecessary_map_on_constructor)]
15#![allow(clippy::useless_conversion)]
16#![allow(clippy::deprecated_semver)]
17#![allow(rustdoc::bare_urls)]
18#![allow(rustdoc::redundant_explicit_links)]
19#![allow(rustdoc::broken_intra_doc_links)]
20#![allow(rustdoc::invalid_html_tags)]
21#![forbid(unsafe_code)]
22#![warn(missing_docs)]
23#![cfg_attr(docsrs, feature(doc_cfg))]
24//! CodeDeploy is a deployment service that automates application deployments to Amazon EC2 instances, on-premises instances running in your own facility, serverless Lambda functions, or applications in an Amazon ECS service.
25//!
26//! You can deploy a nearly unlimited variety of application content, such as an updated Lambda function, updated applications in an Amazon ECS service, code, web and configuration files, executables, packages, scripts, multimedia files, and so on. CodeDeploy can deploy application content stored in Amazon S3 buckets, GitHub repositories, or Bitbucket repositories. You do not need to make changes to your existing code before you can use CodeDeploy.
27//!
28//! CodeDeploy makes it easier for you to rapidly release new features, helps you avoid downtime during application deployment, and handles the complexity of updating your applications, without many of the risks associated with error-prone manual deployments.
29//!
30//! __CodeDeploy Components__
31//!
32//! Use the information in this guide to help you work with the following CodeDeploy components:
33//!   - __Application__: A name that uniquely identifies the application you want to deploy. CodeDeploy uses this name, which functions as a container, to ensure the correct combination of revision, deployment configuration, and deployment group are referenced during a deployment.
34//!   - __Deployment group__: A set of individual instances, CodeDeploy Lambda deployment configuration settings, or an Amazon ECS service and network details. A Lambda deployment group specifies how to route traffic to a new version of a Lambda function. An Amazon ECS deployment group specifies the service created in Amazon ECS to deploy, a load balancer, and a listener to reroute production traffic to an updated containerized application. An Amazon EC2/On-premises deployment group contains individually tagged instances, Amazon EC2 instances in Amazon EC2 Auto Scaling groups, or both. All deployment groups can specify optional trigger, alarm, and rollback settings.
35//!   - __Deployment configuration__: A set of deployment rules and deployment success and failure conditions used by CodeDeploy during a deployment.
36//!   - __Deployment__: The process and the components used when updating a Lambda function, a containerized application in an Amazon ECS service, or of installing content on one or more instances.
37//!   - __Application revisions__: For an Lambda deployment, this is an AppSpec file that specifies the Lambda function to be updated and one or more functions to validate deployment lifecycle events. For an Amazon ECS deployment, this is an AppSpec file that specifies the Amazon ECS task definition, container, and port where production traffic is rerouted. For an EC2/On-premises deployment, this is an archive file that contains source content—source code, webpages, executable files, and deployment scripts—along with an AppSpec file. Revisions are stored in Amazon S3 buckets or GitHub repositories. For Amazon S3, a revision is uniquely identified by its Amazon S3 object key and its ETag, version, or both. For GitHub, a revision is uniquely identified by its commit ID.
38//!
39//! This guide also contains information to help you get details about the instances in your deployments, to make on-premises instances available for CodeDeploy deployments, to get details about a Lambda function deployment, and to get details about Amazon ECS service deployments.
40//!
41//! __CodeDeploy Information Resources__
42//!   - [CodeDeploy User Guide](https://docs.aws.amazon.com/codedeploy/latest/userguide)
43//!   - [CodeDeploy API Reference Guide](https://docs.aws.amazon.com/codedeploy/latest/APIReference/)
44//!   - [CLI Reference for CodeDeploy](https://docs.aws.amazon.com/cli/latest/reference/deploy/index.html)
45//!   - [CodeDeploy Developer Forum](https://forums.aws.amazon.com/forum.jspa?forumID=179)
46//!
47//! ## Getting Started
48//!
49//! > Examples are available for many services and operations, check out the
50//! > [usage examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1).
51//!
52//! The SDK provides one crate per AWS service. You must add [Tokio](https://crates.io/crates/tokio)
53//! as a dependency within your Rust project to execute asynchronous code. To add `aws-sdk-codedeploy` to
54//! your project, add the following to your **Cargo.toml** file:
55//!
56//! ```toml
57//! [dependencies]
58//! aws-config = { version = "1.1.7", features = ["behavior-version-latest"] }
59//! aws-sdk-codedeploy = "1.97.0"
60//! tokio = { version = "1", features = ["full"] }
61//! ```
62//!
63//! Then in code, a client can be created with the following:
64//!
65//! ```rust,no_run
66//! use aws_sdk_codedeploy as codedeploy;
67//!
68//! #[::tokio::main]
69//! async fn main() -> Result<(), codedeploy::Error> {
70//!     let config = aws_config::load_from_env().await;
71//!     let client = aws_sdk_codedeploy::Client::new(&config);
72//!
73//!     // ... make some calls with the client
74//!
75//!     Ok(())
76//! }
77//! ```
78//!
79//! See the [client documentation](https://docs.rs/aws-sdk-codedeploy/latest/aws_sdk_codedeploy/client/struct.Client.html)
80//! for information on what calls can be made, and the inputs and outputs for each of those calls.
81//!
82//! ## Using the SDK
83//!
84//! Until the SDK is released, we will be adding information about using the SDK to the
85//! [Developer Guide](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/welcome.html). Feel free to suggest
86//! additional sections for the guide by opening an issue and describing what you are trying to do.
87//!
88//! ## Getting Help
89//!
90//! * [GitHub discussions](https://github.com/awslabs/aws-sdk-rust/discussions) - For ideas, RFCs & general questions
91//! * [GitHub issues](https://github.com/awslabs/aws-sdk-rust/issues/new/choose) - For bug reports & feature requests
92//! * [Generated Docs (latest version)](https://awslabs.github.io/aws-sdk-rust/)
93//! * [Usage examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1)
94//!
95//!
96//! # Crate Organization
97//!
98//! The entry point for most customers will be [`Client`], which exposes one method for each API
99//! offered by AWS CodeDeploy. The return value of each of these methods is a "fluent builder",
100//! where the different inputs for that API are added by builder-style function call chaining,
101//! followed by calling `send()` to get a [`Future`](std::future::Future) that will result in
102//! either a successful output or a [`SdkError`](crate::error::SdkError).
103//!
104//! Some of these API inputs may be structs or enums to provide more complex structured information.
105//! These structs and enums live in [`types`](crate::types). There are some simpler types for
106//! representing data such as date times or binary blobs that live in [`primitives`](crate::primitives).
107//!
108//! All types required to configure a client via the [`Config`](crate::Config) struct live
109//! in [`config`](crate::config).
110//!
111//! The [`operation`](crate::operation) module has a submodule for every API, and in each submodule
112//! is the input, output, and error type for that API, as well as builders to construct each of those.
113//!
114//! There is a top-level [`Error`](crate::Error) type that encompasses all the errors that the
115//! client can return. Any other error type can be converted to this `Error` type via the
116//! [`From`](std::convert::From) trait.
117//!
118//! The other modules within this crate are not required for normal usage.
119
120// Code generated by software.amazon.smithy.rust.codegen.smithy-rs. DO NOT EDIT.
121pub use error_meta::Error;
122
123#[doc(inline)]
124pub use config::Config;
125
126/// Client for calling AWS CodeDeploy.
127/// ## Constructing a `Client`
128///
129/// A [`Config`] is required to construct a client. For most use cases, the [`aws-config`]
130/// crate should be used to automatically resolve this config using
131/// [`aws_config::load_from_env()`], since this will resolve an [`SdkConfig`] which can be shared
132/// across multiple different AWS SDK clients. This config resolution process can be customized
133/// by calling [`aws_config::from_env()`] instead, which returns a [`ConfigLoader`] that uses
134/// the [builder pattern] to customize the default config.
135///
136/// In the simplest case, creating a client looks as follows:
137/// ```rust,no_run
138/// # async fn wrapper() {
139/// let config = aws_config::load_from_env().await;
140/// let client = aws_sdk_codedeploy::Client::new(&config);
141/// # }
142/// ```
143///
144/// Occasionally, SDKs may have additional service-specific values that can be set on the [`Config`] that
145/// is absent from [`SdkConfig`], or slightly different settings for a specific client may be desired.
146/// The [`Builder`](crate::config::Builder) struct implements `From<&SdkConfig>`, so setting these specific settings can be
147/// done as follows:
148///
149/// ```rust,no_run
150/// # async fn wrapper() {
151/// let sdk_config = ::aws_config::load_from_env().await;
152/// let config = aws_sdk_codedeploy::config::Builder::from(&sdk_config)
153/// # /*
154///     .some_service_specific_setting("value")
155/// # */
156///     .build();
157/// # }
158/// ```
159///
160/// See the [`aws-config` docs] and [`Config`] for more information on customizing configuration.
161///
162/// _Note:_ Client construction is expensive due to connection thread pool initialization, and should
163/// be done once at application start-up.
164///
165/// [`Config`]: crate::Config
166/// [`ConfigLoader`]: https://docs.rs/aws-config/*/aws_config/struct.ConfigLoader.html
167/// [`SdkConfig`]: https://docs.rs/aws-config/*/aws_config/struct.SdkConfig.html
168/// [`aws-config` docs]: https://docs.rs/aws-config/*
169/// [`aws-config`]: https://crates.io/crates/aws-config
170/// [`aws_config::from_env()`]: https://docs.rs/aws-config/*/aws_config/fn.from_env.html
171/// [`aws_config::load_from_env()`]: https://docs.rs/aws-config/*/aws_config/fn.load_from_env.html
172/// [builder pattern]: https://rust-lang.github.io/api-guidelines/type-safety.html#builders-enable-construction-of-complex-values-c-builder
173/// # Using the `Client`
174///
175/// A client has a function for every operation that can be performed by the service.
176/// For example, the [`BatchGetApplicationRevisions`](crate::operation::batch_get_application_revisions) operation has
177/// a [`Client::batch_get_application_revisions`], function which returns a builder for that operation.
178/// The fluent builder ultimately has a `send()` function that returns an async future that
179/// returns a result, as illustrated below:
180///
181/// ```rust,ignore
182/// let result = client.batch_get_application_revisions()
183///     .application_name("example")
184///     .send()
185///     .await;
186/// ```
187///
188/// The underlying HTTP requests that get made by this can be modified with the `customize_operation`
189/// function on the fluent builder. See the [`customize`](crate::client::customize) module for more
190/// information.
191/// # Waiters
192///
193/// This client provides `wait_until` methods behind the [`Waiters`](crate::client::Waiters) trait.
194/// To use them, simply import the trait, and then call one of the `wait_until` methods. This will
195/// return a waiter fluent builder that takes various parameters, which are documented on the builder
196/// type. Once parameters have been provided, the `wait` method can be called to initiate waiting.
197///
198/// For example, if there was a `wait_until_thing` method, it could look like:
199/// ```rust,ignore
200/// let result = client.wait_until_thing()
201///     .thing_id("someId")
202///     .wait(Duration::from_secs(120))
203///     .await;
204/// ```
205pub mod client;
206
207/// Configuration for AWS CodeDeploy.
208pub mod config;
209
210/// Common errors and error handling utilities.
211pub mod error;
212
213mod error_meta;
214
215/// Information about this crate.
216pub mod meta;
217
218/// All operations that this crate can perform.
219pub mod operation;
220
221/// Primitives such as `Blob` or `DateTime` used by other types.
222pub mod primitives;
223
224/// Data structures used by operation inputs/outputs.
225pub mod types;
226
227mod observability_feature;
228
229pub(crate) mod protocol_serde;
230
231mod sdk_feature_tracker;
232
233mod serialization_settings;
234
235mod endpoint_lib;
236
237mod lens;
238
239/// Supporting types for waiters.
240///
241/// Note: to use waiters, import the [`Waiters`](crate::client::Waiters) trait, which adds methods prefixed with `wait_until` to the client.
242pub mod waiters;
243
244mod json_errors;
245
246#[doc(inline)]
247pub use client::Client;