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