Crate aws_sdk_codepipeline

Overview

This is the CodePipeline API Reference. This guide provides descriptions of the actions and data types for CodePipeline. Some functionality for your pipeline can only be configured through the API. For more information, see the CodePipeline User Guide.

You can use the CodePipeline API to work with pipelines, stages, actions, and transitions.

Pipelines are models of automated release processes. Each pipeline is uniquely named, and consists of stages, actions, and transitions.

You can work with pipelines by calling:

• CreatePipeline, which creates a uniquely named pipeline.
• DeletePipeline, which deletes the specified pipeline.
• GetPipeline, which returns information about the pipeline structure and pipeline metadata, including the pipeline Amazon Resource Name (ARN).
• GetPipelineExecution, which returns information about a specific execution of a pipeline.
• GetPipelineState, which returns information about the current state of the stages and actions of a pipeline.
• ListActionExecutions, which returns action-level details for past executions. The details include full stage and action-level details, including individual action duration, status, any errors that occurred during the execution, and input and output artifact location details.
• ListPipelines, which gets a summary of all of the pipelines associated with your account.
• ListPipelineExecutions, which gets a summary of the most recent executions for a pipeline.
• StartPipelineExecution, which runs the most recent revision of an artifact through the pipeline.
• StopPipelineExecution, which stops the specified pipeline execution from continuing through the pipeline.
• UpdatePipeline, which updates a pipeline with edits or changes to the structure of the pipeline.

Pipelines include stages. Each stage contains one or more actions that must complete before the next stage begins. A stage results in success or failure. If a stage fails, the pipeline stops at that stage and remains stopped until either a new version of an artifact appears in the source location, or a user takes action to rerun the most recent artifact through the pipeline. You can call GetPipelineState, which displays the status of a pipeline, including the status of stages in the pipeline, or GetPipeline, which returns the entire structure of the pipeline, including the stages of that pipeline. For more information about the structure of stages and actions, see CodePipeline Pipeline Structure Reference.

Pipeline stages include actions that are categorized into categories such as source or build actions performed in a stage of a pipeline. For example, you can use a source action to import artifacts into a pipeline from a source such as Amazon S3. Like stages, you do not work with actions directly in most cases, but you do define and interact with actions when working with pipeline operations such as CreatePipeline and GetPipelineState. Valid action categories are:

• Source
• Build
• Test
• Deploy
• Approval
• Invoke

Pipelines also include transitions, which allow the transition of artifacts from one stage to the next in a pipeline after the actions in one stage complete.

You can work with transitions by calling:

• DisableStageTransition, which prevents artifacts from transitioning to the next stage in a pipeline.
• EnableStageTransition, which enables transition of artifacts between stages in a pipeline.

Using the API to integrate with CodePipeline

For third-party integrators or developers who want to create their own integrations with CodePipeline, the expected sequence varies from the standard API user. To integrate with CodePipeline, developers need to work with the following items:

Jobs, which are instances of an action. For example, a job for a source action might import a revision of an artifact from a source.

You can work with jobs by calling:

• AcknowledgeJob, which confirms whether a job worker has received the specified job.
• GetJobDetails, which returns the details of a job.
• PollForJobs, which determines whether there are any jobs to act on.
• PutJobFailureResult, which provides details of a job failure.
• PutJobSuccessResult, which provides details of a job success.

Third party jobs, which are instances of an action created by a partner action and integrated into CodePipeline. Partner actions are created by members of the Amazon Web Services Partner Network.

You can work with third party jobs by calling:

• AcknowledgeThirdPartyJob, which confirms whether a job worker has received the specified job.
• GetThirdPartyJobDetails, which requests the details of a job for a partner action.
• PollForThirdPartyJobs, which determines whether there are any jobs to act on.
• PutThirdPartyJobFailureResult, which provides details of a job failure.
• PutThirdPartyJobSuccessResult, which provides details of a job success.

Getting Started

Examples are available for many services and operations, check out the examples folder in GitHub.

The SDK provides one crate per AWS service. You must add Tokio as a dependency within your Rust project to execute asynchronous code. To add aws-sdk-codepipeline to your project, add the following to your Cargo.toml file:

[dependencies]
aws-config = { version = "1.1.7", features = ["behavior-version-latest"] }
aws-sdk-codepipeline = "1.24.0"
tokio = { version = "1", features = ["full"] }

Then in code, a client can be created with the following:

use aws_sdk_codepipeline as codepipeline;

#[::tokio::main]
async fn main() -> Result<(), codepipeline::Error> {
    let config = aws_config::load_from_env().await;
    let client = aws_sdk_codepipeline::Client::new(&config);

    // ... make some calls with the client

    Ok(())
}

See the client documentation for information on what calls can be made, and the inputs and outputs for each of those calls.

Using the SDK

Until the SDK is released, we will be adding information about using the SDK to the Developer Guide. Feel free to suggest additional sections for the guide by opening an issue and describing what you are trying to do.

Getting Help

• GitHub discussions - For ideas, RFCs & general questions
• GitHub issues - For bug reports & feature requests
• Generated Docs (latest version)
• Usage examples

Crate Organization

The entry point for most customers will be Client, which exposes one method for each API offered by AWS CodePipeline. The return value of each of these methods is a “fluent builder”, where the different inputs for that API are added by builder-style function call chaining, followed by calling send() to get a Future that will result in either a successful output or a SdkError.

Some of these API inputs may be structs or enums to provide more complex structured information. These structs and enums live in types. There are some simpler types for representing data such as date times or binary blobs that live in primitives.

All types required to configure a client via the Config struct live in config.

The operation module has a submodule for every API, and in each submodule is the input, output, and error type for that API, as well as builders to construct each of those.

There is a top-level Error type that encompasses all the errors that the client can return. Any other error type can be converted to this Error type via the From trait.

The other modules within this crate are not required for normal usage.

Modules

• client
  Client for calling AWS CodePipeline.
• config
  Configuration for AWS CodePipeline.
• error
  Common errors and error handling utilities.
• meta
  Information about this crate.
• operation
  All operations that this crate can perform.
• primitives
  Primitives such as Blob or DateTime used by other types.
• types
  Data structures used by operation inputs/outputs.

Structs

• Client
  Client for AWS CodePipeline
• Config
  Configuration for a aws_sdk_codepipeline service client.

Enums

• Error
  All possible error types for this service.