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