# What is AWS CodePipeline? AWS CodePipeline is a continuous delivery service you can use to model, visualize, and automate the steps required to release your software. You can quickly model and configure the different stages of a software release process. CodePipeline automates the steps required to release your software changes continuously. For information about pricing for CodePipeline, see [Pricing](https://aws.amazon.com/codepipeline/pricing/). **Topics** + [ # Continuous delivery and continuous integration ](concepts-continuous-delivery-integration.md) + [ # What can I do with CodePipeline? ](welcome-what-can-I-do.md) + [ # A quick look at CodePipeline ](welcome-introducing.md) + [ # How do I get started with CodePipeline? ](welcome-get-started.md) + [ # CodePipeline concepts ](concepts.md) + [ # DevOps pipeline example ](concepts-devops-example.md) + [ # How pipeline executions work ](concepts-how-it-works.md) + [ # Input and output artifacts ](welcome-introducing-artifacts.md) + [ # How do stage conditions work? ](concepts-how-it-works-conditions.md) + [ # Pipeline types ](pipeline-types.md) + [ # What type of pipeline is right for me? ](pipeline-types-planning.md) # Continuous delivery and continuous integration CodePipeline is a *continuous delivery* service that automates the building, testing, and deployment of your software into production. [Continuous delivery](https://aws.amazon.com/devops/continuous-delivery/) is a software development methodology where the release process is automated. Every software change is automatically built, tested, and deployed to production. Before the final push to production, a person, an automated test, or a business rule decides when the final push should occur. Although every successful software change can be immediately released to production with continuous delivery, not all changes need to be released right away. [Continuous integration](https://aws.amazon.com/devops/continuous-integration/) is a software development practice where members of a team use a version control system and frequently integrate their work to the same location, such as a main branch. Each change is built and verified to detect integration errors as quickly as possible. Continuous integration is focused on automatically building and testing code, as compared to *continuous delivery*, which automates the entire software release process up to production. For more information, see [Practicing Continuous Integration and Continuous Delivery on AWS: Accelerating Software Delivery with DevOps](https://d0.awsstatic.com/whitepapers/DevOps/practicing-continuous-integration-continuous-delivery-on-AWS.pdf). You can use the CodePipeline console, the AWS Command Line Interface (AWS CLI), the AWS SDKs, or any combination of these to create and manage your pipelines. # What can I do with CodePipeline? You can use CodePipeline to help you automatically build, test, and deploy your applications in the cloud. Specifically, you can: + **Automate your release processes**: CodePipeline fully automates your release process from end to end, starting from your source repository through build, test, and deployment. You can prevent changes from moving through a pipeline by including a manual approval action in any stage except a Source stage. You can release when you want, in the way you want, on the systems of your choice, across one instance or multiple instances. + **Establish a consistent release process**: Define a consistent set of steps for every code change. CodePipeline runs each stage of your release according to your criteria. + **Speed up delivery while improving quality**: You can automate your release process to allow your developers to test and release code incrementally and speed up the release of new features to your customers. + **Use your favorite tools**: You can incorporate your existing source, build, and deployment tools into your pipeline. For a full list of AWS services and third-party tools currently supported by CodePipeline, see [Product and service integrations with CodePipeline](integrations.md). + **View progress at a glance**: You can review real-time status of your pipelines, check the details of any alerts, retry failed stages or actions, view details about the source revisions used in the latest pipeline execution in each stage, and manually rerun any pipeline. + **View pipeline history details**: You can view details about executions of a pipeline, including start and end times, run duration, and execution IDs. # A quick look at CodePipeline The following diagram shows an example release process using CodePipeline. ![\[An example release process using CodePipeline.\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/PipelineFlow.png) In this example, when developers commit changes to a source repository, CodePipeline automatically detects the changes. Those changes are built, and if any tests are configured, those tests are run. After the tests are complete, the built code is deployed to staging servers for testing. From the staging server, CodePipeline runs more tests, such as integration or load tests. Upon the successful completion of those tests, and after a manual approval action that was added to the pipeline is approved, CodePipeline deploys the tested and approved code to production instances. CodePipeline can deploy applications to EC2 instances by using CodeDeploy, AWS Elastic Beanstalk, or AWS OpsWorks Stacks. CodePipeline can also deploy container-based applications to services by using Amazon ECS. Developers can also use the integration points provided with CodePipeline to plug in other tools or services, including build services, test providers, or other deployment targets or systems. A pipeline can be as simple or as complex as your release process requires. # How do I get started with CodePipeline? To get started with CodePipeline: 1. **Learn** how CodePipeline works by reading the [CodePipeline concepts](concepts.md) section. 1. **Prepare** to use CodePipeline by following the steps in [Getting started with CodePipeline](getting-started-codepipeline.md). 1. **Experiment** with CodePipeline by following the steps in the [CodePipeline tutorials](tutorials.md) tutorials. 1. **Use** CodePipeline for your new or existing projects by following the steps in [Create a pipeline, stages, and actions](pipelines-create.md). # CodePipeline concepts Modeling and configuring your automated release process is easier if you understand the concepts and terms used in AWS CodePipeline. Here are some concepts to know about as you use CodePipeline. For an example of a DevOps pipeline, see [DevOps pipeline example](concepts-devops-example.md). The following terms are used in CodePipeline: **Topics** + [ ## Pipelines ](#concepts-pipelines) + [ ## Pipeline executions ](#concepts-executions) + [ ## Stage operations ](#concepts-stage-executions) + [ ## Action executions ](#concepts-action-executions) + [ ## Execution types ](#concepts-execution-types) + [ ## Action types ](#concepts-action-types) + [ ## Artifacts ](#concepts-artifacts) + [ ## Source revisions ](#concepts-source-revisions) + [ ## Triggers ](#concepts-triggers) + [ ## Variables ](#concepts-variables) + [ ## Conditions ](#concepts-conditions) + [ ## Rules ](#concepts-rules) ## Pipelines A *pipeline* is a workflow construct that describes how software changes go through a release process. Each pipeline is made up of a series of *stages*. ### Stages A stage is a logical unit you can use to isolate an environment and to limit the number of concurrent changes in that environment. Each stage contains actions that are performed on the application [artifacts](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts). Your source code is an example of an artifact. A stage might be a build stage, where the source code is built and tests are run. It can also be a deployment stage, where code is deployed to runtime environments. Each stage is made up of a series of serial or parallel *actions*. ### Transitions A *transition* is the point where a pipeline execution moves to the next stage in the pipeline. You can disable a stage's inbound transition to prevent executions from entering that stage, and then you can enable the transition to allow executions to continue. When more than one execution arrives at a disabled transition, only the latest execution continues to the next stage when the transition is enabled. This means that newer executions continue to supersede waiting executions while the transition is disabled, and then after the transition is enabled, the execution that continues is the superseding execution. ![\[A pipeline contains stages, which contain actions, which are separated by transitions that can be disabled and enabled.\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/pipeline-elements-workflow.png) ### Actions An *action* is a set of operations performed on application code and configured so that the actions run in the pipeline at a specified point. This can include things like a source action from a code change, an action for deploying the application to instances, and so on. For example, a deployment stage might contain a deployment action that deploys code to a compute service like Amazon EC2 or AWS Lambda. Valid CodePipeline action types are `source`, `build`, `test`, `deploy`, `approval`, and `invoke`. For a list of action providers, see [Valid action providers in CodePipeline](actions-valid-providers.md). Actions can run in series or in parallel. For information about serial and parallel actions in a stage, see the `runOrder` information in [action structure requirements](https://docs.aws.amazon.com/codepipeline/latest/userguide/reference-pipeline-structure.html#action-requirements). ## Pipeline executions An *execution* is a set of changes released by a pipeline. Each pipeline execution is unique and has its own ID. An execution corresponds to a set of changes, such as a merged commit or a manual release of the latest commit. Two executions can release the same set of changes at different times. While a pipeline can process multiple executions at the same time, a pipeline stage processes only one execution at a time. To do this, a stage is locked while it processes an execution. Two pipeline executions can't occupy the same stage at the same time. The execution waiting to enter the occupied stage is referred to an *inbound execution*. An inbound execution can still fail, be superseded, or be manually stopped. For more information about how inbound executions work, see [How Inbound Executions Work](concepts-how-it-works.md#how-it-works-inbound-executions). Pipeline executions traverse pipeline stages in order. Valid statuses for pipelines are `InProgress`, `Stopping`, `Stopped`, `Succeeded`, `Superseded`, and `Failed`. For more information, see [PipelineExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineExecution.html). ### Stopped executions The pipeline execution can be stopped manually so that the in-progress pipeline execution does not continue through the pipeline. If stopped manually, a pipeline execution shows a `Stopping` status until it is completely stopped. Then it shows a `Stopped` status. A `Stopped` pipeline execution can be retried. There are two ways to stop a pipeline execution: + **Stop and wait** + **Stop and abandon** For information about use cases for stopping an execution and sequence details for these options, see [How pipeline executions are stopped](concepts-how-it-works.md#concepts-how-it-works-stopping). ### Failed executions If an execution fails, it stops and does not completely traverse the pipeline. Its status is `FAILED` status and the stage is unlocked. A more recent execution can catch up and enter the unlocked stage and lock it. You can retry a failed execution unless the failed execution has been superseded or is not retryable. You can roll back a failed stage to a previous successful execution. ### Execution modes To deliver the latest set of changes through a pipeline, newer executions pass and replace less recent executions already running through the pipeline. When this occurs, the older execution is superseded by the newer execution. An execution can be superseded by a more recent execution at a certain point, which is the point between stages. SUPERSEDED is the default execution mode. In SUPERSEDED mode, if an execution is waiting to enter a locked stage, a more recent execution might catch up and supersede it. The newer execution now waits for the stage to unlock, and the superseded execution stops with a `SUPERSEDED` status. When a pipeline execution is superseded, the execution is stopped and does not completely traverse the pipeline. You can no longer retry the superseded execution after it has been replaced at this stage. Other available execution modes are PARALLEL or QUEUED mode. For more information about execution modes and locked stages, see [How executions are processed in SUPERSEDED mode](concepts-how-it-works.md#concepts-how-it-works-executions). ## Stage operations When a pipeline execution runs through a stage, the stage is in the process of completing all of the actions within it. For information about how stage operations work and information about locked stages, see [How executions are processed in SUPERSEDED mode](concepts-how-it-works.md#concepts-how-it-works-executions). Valid statuses for stages are `InProgress`, `Stopping`, `Stopped`, `Succeeded`, and `Failed`. You can retry a failed stage unless the failed stage is not retryable. For more information, see [StageExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageExecution.html). You can roll back a stage to a specified previous successful execution. A stage can be configured to roll back automatically on failure as detailed in [Configuring stage rollback](stage-rollback.md). For more information, see [RollbackStage](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RollbackStage.html). ## Action executions An *action execution* is the process of completing a configured action that operates on designated [artifacts](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts). These can be input artifacts, output artifacts, or both. For example, a build action might run build commands on an input artifact, such as compiling application source code. Action execution details include an action execution ID, the related pipeline execution source trigger, and the input and output artifacts for the action. Valid statuses for actions are `InProgress`, `Abandoned`, `Succeeded`, or `Failed`. For more information, see [ActionExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_ActionExecution.html). ## Execution types A pipeline or stage execution can be either a standard or a rolled-back execution. For standard types, the execution has a unique ID and is a full pipeline run. A pipeline rollback has a stage to be rolled back and a successful execution for the stage as the target execution to which to roll back. The target pipeline execution is used to retrieve source revisions and variables for the stage to rerun. ## Action types *Action types* are preconfigured actions that are available for selection in CodePipeline. The action type is defined by its owner, provider, version, and category. The action type provides customized parameters that are used to complete the action tasks in a pipeline. For information about the AWS services and third-party products and services you can integrate into your pipeline based on action type, see [Integrations with CodePipeline action types](integrations-action-type.md). For information about the integration models supported for action types in CodePipeline, see [Integration model reference](reference-integrations.md). For information about how third-party providers can set up and manage action types in CodePipeline, see [Working with action types](action-types.md). ## Artifacts *Artifacts* refers to the collection of data, such as application source code, built applications, dependencies, definitions files, templates, and so on, that is worked on by pipeline actions. Artifacts are produced by some actions and consumed by others. In a pipeline, artifacts can be the set of files worked on by an action (*input artifacts*) or the updated output of a completed action (*output artifacts*). Actions pass output to another action for further processing using the pipeline artifact bucket. CodePipeline copies artifacts to the artifact store, where the action picks them up. For more information about artifacts, see [Input and output artifacts](welcome-introducing-artifacts.md). ## Source revisions When you make a source code change, a new version is created. A *source revision* is the version of a source change that triggers a pipeline execution. An execution processes source revisions. For GitHub and CodeCommit repositories, this is the commit. For S3 buckets or actions, this is the object version. You can start a pipeline execution with a source revision, such as a commit, that you specify. The execution will process the specified revision and override what would have been the revision used for the execution. For more information, see [Start a pipeline with a source revision override](pipelines-trigger-source-overrides.md). ## Triggers *Triggers* are events that start your pipeline. Some triggers, such as starting a pipeline manually, are available for all source action providers in a pipeline. Certain triggers depend on the source provider for a pipeline. For example, CloudWatch events must be configured with event resources from Amazon CloudWatch that have the pipeline ARN added as a target in the event rule. Amazon CloudWatch Events is the recommended trigger for automatic change detection for pipelines with a CodeCommit or S3 source action. Webhooks are a type of trigger configured for third-party repository events. For example, WebhookV2 is a trigger type that allows Git tags to be used to start pipelines with third-party source providers such as GitHub.com, GitHub Enterprise Server, GitLab.com, GitLab self-managed, or Bitbucket Cloud. In the pipeline configuration, you can specify a filter for triggers, such as push or pull request. You can filter code push events on Git tags, branches, or file paths. You can filter pull request events on event (opened, updated, closed), branches, or file paths. For more information about triggers, see [Start a pipeline in CodePipeline](pipelines-about-starting.md). For a tutorial that walks you through using Git tags as triggers for your pipeline, see [Tutorial: Use Git tags to start your pipeline](tutorials-github-tags.md). **Important** Pipelines that are inactive for longer than 30 days will have polling disabled for the pipeline. For more information, see [pollingDisabledAt](pipeline-requirements.md#metadata.pollingDisabledAt) in the pipeline structure reference. For the steps to migrate your pipeline from polling to event-based change detection, see [Change Detection Methods](change-detection-methods.md). ## Variables A *variable* is a value that can be used to dynamically configure actions in your pipeline. Variables can be either declared on the pipeline level, or emitted by actions in the pipeline. Variable values are resolved at the time of pipeline execution and can be viewed in the execution history. For variables declared at the pipeline level, you can either define default values in the pipeline configuration, or override them for a given execution. For variables emitted by an action, the value is available after an action succesfully completes. For more information, see [Variables reference](reference-variables.md). ## Conditions A *condition* contains a set of rules that are evaluated. If all rules in a condition succeed, then the condition is met. You can configure conditions so that when the criteria are not met, the specified result, such as failing the stage, engages. Conditions are also referred to as gates because they allow you to specify when an execution will enter and run through a stage or exit the stage after running through it. This is analogous to allowing a line of traffic on a roadway to gather at a closed gate, and then specifying the opening of the gate to allow flow of traffic into an area. Results for condition types include failing the stage or rolling back the stage. Conditions help you to specify when these actions happen in a pipeline stage. You can override conditions at runtime. There are three types of conditions. Entry conditions answer the question “If the rules for the condition are met, then enter the stage.” The stage is locked when the execution enters the stage, and then the rules are run. For On Failure conditions, the rule engages when a stage has failed, with a result of rolling back a failed stage. For On Success conditions, the rule engages when a stage is successful, such as checking a successful run for alarms before proceeding. For example, an On Success condition would result in a rollback of a successful stage if the CloudWatchAlarm rule finds that there are alarms in the deployment environment. For more information, see [How do stage conditions work?](concepts-how-it-works-conditions.md). ## Rules Conditions use one or more preconfigured *rules* that run and perform checks that will then engage the configured result for when the condition is not met. For example, meeting all rules for an Entry condition rule that checks for alarm status and deployment window times will deploy a successful stage after all checks pass. For more information, see [How do stage conditions work?](concepts-how-it-works-conditions.md). # DevOps pipeline example As an example of a DevOps pipeline, a two-stage pipeline might have a source stage called **Source** and a second stage called **Prod**. In this example, the pipeline is updating the application with the latest changes and continuously deploying the latest result. Before it deploys the latest application, the pipeline builds and tests the web application. In this example, a group of developers have set up an infrastructure template and the source code for a web application in a GitHub repository called MyRepository. ![\[A pipeline with sample stages and actions.\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/pipeline-elements-workflow-application.png) For example, a developer pushes a fix to the web application's index page, and the following occurs: 1. The application source code is maintained in a repository configured as a GitHub source action in the pipeline. When developers push commits to the repository, CodePipeline detects the pushed change, and a pipeline execution starts from the **Source Stage**. 1. The GitHub source action completes successfully (that is, the latest changes have been downloaded and stored to the artifact bucket unique to that execution). The *output artifacts* produced by the GitHub source action, which are the application files from the repository, are then used as the *input artifacts* to be worked on by the actions in the next stage. 1. The pipeline execution transitions from the **Source Stage** to the **Prod Stage**. The first action in the **Prod Stage** runs a build project created in CodeBuild and configured as a build action in the pipeline. The build task pulls a build environment image and builds the web application in a virtual container. 1. The next action in the **Prod Stage** is a unit test project created in CodeBuild and configured as a test action in the pipeline. 1. The unit tested code is next worked on by a deploy action in the **Prod Stage** that deploys the application to a production environment. After the deploy action completes successfully, the final action in the stage is an integration testing project created in CodeBuild and configured as a test action in the pipeline. The test action calls to shell scripts that install and run a test tool, such as a link checker, on the web application. After successful completion, the output is a built web application and a set of test results. Developers can add actions to the pipeline that deploy or further test the application after it is built and tested for each change. For more information, see [How pipeline executions work](concepts-how-it-works.md). # How pipeline executions work This section provides an overview of the way CodePipeline processes a set of changes. CodePipeline tracks each pipeline execution that starts when a pipeline is started manually or a change is made to the source code. CodePipeline uses the following execution modes to handle the way each execution progresses through the pipeline. For more information, see [Set or change the pipeline execution mode](execution-modes.md). + SUPERSEDED mode: A more recent execution can overtake an older one. This is the default. + QUEUED mode: Executions are processed one by one in the order that they are queued. This requires pipeline type V2. + PARALLEL mode: In PARALLEL mode, executions run simultaneously and independently of one another. Executions don't wait for other runs to complete before starting or finishing. This requires pipeline type V2. **Important** For pipelines in PARALLEL mode, stage rollback is not available. Similarly, failure conditions with a rollback result type cannot be added to a PARALLEL mode pipeline. ## How pipeline executions are started You can start an execution when you change your source code or manually start the pipeline. You can also trigger an execution through an Amazon CloudWatch Events rule that you schedule. For example, when a source code change is pushed to a repository configured as the pipeline's source action, the pipeline detects the change and starts an execution. **Note** If a pipeline contains multiple source actions, all of them run again, even if a change is detected for one source action only. ## How source revisions are processed in pipeline executions For each pipeline execution that starts with source code changes (source revisions), source revisions are determined as follows. + For pipelines with a CodeCommit source, the HEAD is cloned by CodePipeline at the moment that the commit is pushed. For example, a commit is pushed, which starts the pipeline for execution 1. At the moment a second commit is pushed, this starts the pipeline for execution 2. **Note** For pipelines in PARALLEL mode with a CodeCommit source, regardless of the commit that triggered the pipeline execution, the source action will always clone the HEAD at the time it is started. For more information, see [CodeCommit or S3 source revisions in PARALLEL mode might not match EventBridge event](troubleshooting.md#troubleshooting-revisions-parallel). + For pipelines with an S3 source, the EventBridge event for the S3 bucket update is used. For example, the event is generated when a file is updated in the source bucket, which starts the pipeline for execution 1. At the moment that the event for a second bucket update is made, this starts the pipeline for execution 2. **Note** For pipelines in PARALLEL mode with an S3 source, regardless of the image tag that triggered the execution, the source action will always start with the latest image tag. For more information, see [CodeCommit or S3 source revisions in PARALLEL mode might not match EventBridge event](troubleshooting.md#troubleshooting-revisions-parallel). + For pipelines with a connections source, such as to Bitbucket, the HEAD is cloned by CodePipeline at the moment that the commit is pushed. For example, for a pipeline in PARALLEL mode, a commit is pushed, which starts the pipeline for execution 1, and the second pipeline execution uses the second commit. ## How source overrides work with the EventBridge input transformer You can use overrides to start a pipeline with a specific source revision ID that you provide for the pipeline execution. For example, if you want to start a pipeline that will process a specific commit ID from your CodeCommit source, you can add the commit ID as an override when you start your pipeline. There are four types of source revision for `revisionType`: + `COMMIT_ID` + `IMAGE_DIGEST` + `S3_OBJECT_VERSION_ID` + `S3_OBJECT_KEY` **Note** For the `COMMIT_ID` and `IMAGE_DIGEST` types of source revisions, the source revision ID applies to all content in the repository, across all branches. **Note** For the `S3_OBJECT_VERSION_ID` and `S3_OBJECT_KEY` types of source revisions, either of the types can be used independently, or they can be used together to override the source with a specific ObjectKey and VersionID. For `S3_OBJECT_KEY`, the configuration parameter `AllowOverrideForS3ObjectKey` needs to be set to `true`. For more information on S3 source configuration parameters, see [Configuration parameters](action-reference-S3.md#action-reference-S3-config). You can specify source overrides using the input transformer in EventBridge. Use the input transformer to pass the data as one of the following: + You can use the input transformer to pass the data as JSON parameters. + You can use the input transformer to pass pipeline variables. For examples of passing the data as JSON parameters, see [Amazon ECR source actions and EventBridge resources](create-cwe-ecr-source.md), [Connecting to Amazon S3 source actions that use EventBridge and AWS CloudTrail](create-cloudtrail-S3-source.md) for S3, and [CodeCommit source actions and EventBridge](triggering.md) for CodeCommit. ## How pipeline executions are stopped To use the console to stop a pipeline execution, you can choose **Stop execution** on the pipeline visualization page, on the execution history page, or on the detailed history page. To use the CLI to stop a pipeline execution, you use the `stop-pipeline-execution` command. For more information, see [Stop a pipeline execution in CodePipeline](pipelines-stop.md). There are two ways to stop a pipeline execution: + **Stop and wait:** All in-progress action executions are allowed to complete, and subsequent actions are not started. The pipeline execution does not continue to subsequent stages. You cannot use this option on an execution that is already in a `Stopping` state. + **Stop and abandon:** All in-progress action executions are abandoned and do not complete, and subsequent actions are not started. The pipeline execution does not continue to subsequent stages. You can use this option on an execution that is already in a `Stopping` state. **Note** This option can lead to failed tasks or out of sequence tasks. Each option results in a different sequence of pipeline and action execution phases, as follows. **Option 1: Stop and wait** When you choose to stop and wait, the selected execution continues until in-progress actions are completed. For example, the following pipeline execution was stopped while the build action was in progress. 1. In the pipeline view, the success message banner is displayed, and the build action continues until it is completed. The pipeline execution status is **Stopping**. In the history view, the status for in-progress actions, such as the build action, is **In progress** until the build action is completed. While actions are in progress, the pipeline execution status is **Stopping**. 1. The execution stops when the stopping process is complete. If the build action is completed successfully, its status is **Succeeded**, and the pipeline execution shows a status of **Stopped**. Subsequent actions do not start. The **Retry** button is enabled. In the history view, the execution status is **Stopped** after the in-progress action is completed. ![\[Image showing the the history view where the execution status is Stopped after the in-progress action is completed\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/stop-exec-wait-hist-1.png) **Option 2: Stop and abandon** When you choose to stop and abandon, the selected execution does not wait for in-progress actions to complete. The actions are abandoned. For example, the following pipeline execution was stopped and abandoned while the build action was in progress. 1. In the pipeline view, the success banner message is displayed, the build action shows a status of **In progress**, and the pipeline execution shows a status of **Stopping**. 1. After the pipeline execution stops, the build action shows a status of **Abandoned**, and the pipeline execution shows a status of **Stopped**. Subsequent actions do not start. The **Retry** button is enabled. 1. In the history view, the execution status is **Stopped**. ![\[Image showing the the history view where the execution status is Stopped\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/stop-exec-abandon-hist-1.png) **Use cases for stopping a pipeline execution** We recommend that you use the stop and wait option to stop a pipeline execution. This option is safer because it avoids possible failed or out-of-sequence tasks in your pipeline. When an action is abandoned in CodePipeline, the action provider continues any tasks related to the action. In the case of an CloudFormation action, the deployment action in the pipeline is abandoned, but the stack update might continue and result in a failed update. As an example of abandoned actions that can result in out-of-sequence tasks, if you are deploying a large file (1GB) through an S3 deployment action, and you choose to stop and abandon the action while the deployment is already in progress, the action is abandoned in CodePipeline, but continues in Amazon S3. Amazon S3 does not encounter any instruction to cancel the upload. Next, if you start a new pipeline execution with a very small file, there are now two deployments in progress. Because the file size of the new execution is small, the new deployment completes while the old deployment is still uploading. When the old deployment completes, the new file is overwritten by the old file. You might want to use the stop and abandon option in the case where you have a custom action. For example, you can abandon a custom action with work that does not need to finish before starting a new execution for a bug fix. ## How executions are processed in SUPERSEDED mode The default mode for processing executions is SUPERSEDED mode. An execution consists of a set of changes picked up and processed by the execution. Pipelines can process multiple executions at the same time. Each execution is run through the pipeline separately. The pipeline processes each execution in order and might supersede an earlier execution with a later one. The following rules are used to process executions in a pipeline for SUPERSEDED mode. **Rule 1: Stages are locked when an execution is being processed** Because each stage can process only one execution at a time, the stage is locked while in progress. When the execution completes a stage, it transitions to the next stage in the pipeline. ![\[Image showing the stages locked while in progress\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/Promotion.png) **Rule 2: Subsequent executions wait for the stage to be unlocked** While a stage is locked, waiting executions are held in front of the locked stage. All actions configured for a stage must be completed successfully before the stage is considered complete. A failure releases the lock on the stage. When an execution is stopped, the execution does not continue in a stage and the stage is unlocked. **Note** Before you stop an execution, we recommend that you disable the transition in front of the stage. This way, when the stage is unlocked due to the stopped execution, the stage does not accept a subsequent pipeline execution. ![\[Image showing how the waiting execution waits between stages when Stage 2 is locked\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/Waiting.png) **Rule 3: Waiting executions are superseded by more recent executions** Executions are only superseded in between stages. A locked stage holds one execution at the front of the stage awaiting the stage to complete. A more recent execution overtakes a waiting execution and continues to the next stage as soon as the stage is unlocked. The superseded execution does not continue. In this example, Execution 2 has been superseded by Execution 3 while awaiting the locked stage. Execution 3 enters the stage next. ![\[Image showing how the waiting execution is superseded by execution 3\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/Batching.png) For more information about considerations for viewing and switching between execution modes, see [Set or change the pipeline execution mode](execution-modes.md). For more information about quotas with execution modes, see [Quotas in AWS CodePipeline](limits.md). ## How executions are processed in QUEUED mode For pipelines in QUEUED mode, stages are locked when an execution is being processed; however, waiting executions do not overtake executions that have already started. Waiting executions gather at the entry points to locked stages in the order that they reach the stage, forming a queue of waiting executions. With QUEUED mode, you can have multiple queues in the same pipeline. When a queued execution enters a stage, the stage is locked and no other executions can enter. This behavior remains the same as SUPERSEDED mode. When the execution finishes the stage, the stage becomes unlocked and ready for the next execution. The following diagram shows how stages in a QUEUED mode pipeline process executions. For example, while the Source stage processes execution 5, the executions for 6 and 7 form Queue \$11 and wait at the stage entry point. The next execution in the queue will be processed after the stage unlocks. ![\[A diagram showing executions in a pipeline set for QUEUED mode.\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/Queued-Execution-Mode.png) For more information about considerations for viewing and switching between execution modes, see [Set or change the pipeline execution mode](execution-modes.md). For more information about quotas with execution modes, see [Quotas in AWS CodePipeline](limits.md). ## How executions are processed in PARALLEL mode For pipelines in PARALLEL mode, executions are independent of one another and don’t wait for other executions to complete before starting. There are no queues. To view parallel executions in the pipeline, use the execution history view. Use PARALLEL mode in development environments where each feature has its own feature branch and deploys to targets that are not shared by other users. For more information about considerations for viewing and switching between execution modes, see [Set or change the pipeline execution mode](execution-modes.md). For more information about quotas with execution modes, see [Quotas in AWS CodePipeline](limits.md). ## Managing Pipeline Flow The flow of pipeline executions can be controlled by: + A *transition*, which controls the flow of executions into the stage. Transitions can be enabled or disabled. When a transition is disabled, pipeline executions cannot enter the stage. The pipeline execution waiting to enter a stage where the transition is disabled is called the inbound execution. After you enable the transition, an inbound execution moves into the stage and locks it. Similar to executions awaiting a locked stage, when a transition is disabled, the execution waiting to enter the stage can still be superseded by a new execution. When a disabled transition is re-enabled, the latest execution, including any that superseded older executions while the transition was disabled, enters the stage. + An *approval action*, which prevents a pipeline from transitioning to the next action until permission is granted (for example, through manual approval from an authorized identity). You might use an approval action when you want to control the time at which a pipeline transitions to a final **Production** stage, for example. **Note** A stage with an approval action is locked until the approval action is approved or rejected or has timed out. A timed-out approval action is processed in the same way as a failed action. + A *failure*, when an action in a stage does not complete successfully. The revision does not transition to the next action in the stage or the next stage in the pipeline. The following can occur: + You manually retry the stage that contains the failed actions. This resumes the execution (it retries failed actions and, if they succeed, continues in the stage/pipeline). + Another execution enters the failed stage and supersedes the failed execution. At this point, the failed execution cannot be retried. ### Recommended pipeline structure When deciding how a code change should flow through your pipeline, it is best to group related actions within a stage so that, when the stage locks, the actions all process the same execution. You might create a stage for each application environment, AWS Region, or Availability Zone, and so on. A pipeline with too many stages (that is, too granular) can allow too many concurrent changes, while a pipeline with many actions in a large stage (too coarse) can take too long to release a change. As an example, a test action after a deployment action in the same stage is guaranteed to test the same change that was deployed. In this example, a change is deployed to a Test environment and then tested, and then the latest change from the test environment is deployed to a Production environment. In the recommended example, the Test environment and the Prod environment are separate stages. ![\[Image showing two types of grouping for actions in stages, with the recommended option being on the left\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/structure-example-recommended-notrecommended.png) ### How Inbound Executions Work An inbound execution is an execution that is waiting for an unavailable stage, transition, or action to become available before it moves forward. The next stage, transition, or action might be unavailable because: + Another execution has already entered the next stage and locked it. + The transition to enter the next stage is disabled. You might disable a transition to hold an inbound execution if you want to control whether a current execution has time to complete in subsequent stages, or if you want to stop all actions at a certain point. To determine if you have an inbound execution, you can view the pipeline in the console or view the output from the **get-pipeline-state** command. Inbound executions operate with the following considerations: + As soon as the action, transition, or locked stage becomes available, the in-progress inbound execution enters the stage and continues through the pipeline. + While the inbound execution is waiting, it can be manually stopped. An inbound execution can have an `InProgress`, `Stopped`, or `Failed` state. + When an inbound execution has been stopped or has failed, it cannot be retried because there are no failed actions to retry. When an inbound execution has been stopped, and the transition is enabled, the stopped inbound execution does not continue into the stage. You can view or stop an inbound execution. # Input and output artifacts CodePipeline integrates with development tools to check for code changes and then build and deploy through all of the stages of the continuous delivery process. Artifacts are the files that are worked on by actions in the pipeline, such as files or folders with application code, index page files, scripts, and so on. For example, the Amazon S3 source action artifact is a file name (or file path) where the application source code files are provided for the pipeline source action. The files are provided as a ZIP file, such as the following example artifact name: `SampleApp_Windows.zip`. The output artifact for the source action, the application source code files, is the output artifact from that action and is the input artifact for the next action, such as a build action. As another example, a build action might run build commands that compile application source code for an input artifact, which is the application source code files. See the action configuration reference page for a specific action for details about artifact parameters, such as [AWS CodeBuild build and test action reference](action-reference-CodeBuild.md) for the CodeBuild action. Actions use input and output artifacts that are stored in the Amazon S3 artifact bucket you chose when you created the pipeline. CodePipeline zips and transfers the files for input or output artifacts as appropriate for the action type in the stage. **Note** The artifact bucket is not the same bucket as the bucket used as the source file location for a pipeline where the chosen source action is S3. For example: 1. CodePipeline triggers your pipeline to run when there is a commit to the source repository, providing the output artifact (any files to be built) from the **Source** stage. 1. The output artifact (any files to be built) from the previous step is ingested as an input artifact to the **Build** stage. An output artifact (the built application) from the **Build** stage can be an updated application or an updated Docker image built to a container. 1. The output artifact from the previous step (the built application) is ingested as an input artifact to the **Deploy** stage, such as staging or production environments in the AWS Cloud. You can deploy applications to a deployment fleet, or you can deploy container-based applications to tasks running in ECS clusters. When you create or edit an action, you designate the input and output artifact or artifacts for the action. For example, for a two-stage pipeline with a **Source** and **Deploy** stage, in **Edit Action**, you choose the artifact name of the source action for the input artifact for the deploy action. + When you use the console to create your first pipeline, CodePipeline creates an Amazon S3 bucket in the same AWS account and AWS Region to store items for all pipelines. Every time you use the console to create another pipeline in that Region, CodePipeline creates a folder for that pipeline in the bucket. It uses that folder to store artifacts for your pipeline as the automated release process runs. This bucket is named codepipeline-*region*-*12345EXAMPLE*, where *region* is the AWS Region in which you created the pipeline, and *12345EXAMPLE* is a 12-digit random number that ensures the bucket name is unique. **Note** If you already have a bucket starting with codepipeline-*region*- in the Region where you are creating the pipeline, CodePipeline uses that as the default bucket. It also follows lexicographical order; for example, codepipeline-*region-abcexample* is chosen before codepipeline-*region-defexample*. CodePipeline truncates artifact names, which can cause some bucket names to appear similar. Even though the artifact name appears to be truncated, CodePipeline maps to the artifact bucket in a way that is not affected by artifacts with truncated names. The pipeline can function normally. This is not an issue with the folder or artifacts. There is a 100-character limit to pipeline names. Although the artifact folder name might appear to be shortened, it is still unique for your pipeline. When you create or edit a pipeline, you must have an artifact bucket in the pipeline AWS account and AWS Region, and you must have one artifact bucket per Region where you plan to execute an action. If you use the console to create a pipeline or cross-Region actions, default artifact buckets are configured by CodePipeline in the Regions where you have actions. If you use the AWS CLI to create a pipeline, you can store the artifacts for that pipeline in any Amazon S3 bucket as long as that bucket is in the same AWS account and AWS Region as the pipeline. You might do this if you are concerned about exceeding the limits of Amazon S3 buckets allowed for your account. If you use the AWS CLI to create or edit a pipeline, and you add a cross-Region action (an action with an AWS provider in a Region different from your pipeline), you must provide an artifact bucket for each additional Region where you plan to execute an action. + Every action has a type. Depending on the type, the action might have one or both of the following: + An input artifact, which is the artifact it consumes or works on over the course of the action run. + An output artifact, which is the output of the action. Every output artifact in the pipeline must have a unique name. Every input artifact for an action must match the output artifact of an action earlier in the pipeline, whether that action is immediately before the action in a stage or runs in a stage several stages earlier. An artifact can be worked on by more than one action. # How do stage conditions work? For each condition that specifies a rule, the rule is run. If the condition fails, the result is engaged. The stage performs the specified result only when the condition fails. Optionally, as part of the rule, you also specify which resources CodePipeline should use for certain cases. For example, the `CloudWatchAlarm` rule will use a CloudWatch alarm resource to run checks for the condition. A condition might match multiple rules, and each rule can specify one of three providers. The high-level flow for creating conditions as as follows. 1. Choose the type of condition from the available condition types in CodePipeline. For example, use an On Success condition type to set up a stage so that after the stage succeeds, a set of rules can be used to run checks before proceeding. 1. Choose the rule. For example, the `CloudWatchAlarm` rule will check for alarms and uses EB to check for a preconfigured alarm threshold. If the check is successful, and the alarm is below the threshold, the stage can proceed. 1. Configure the result, such as a rollback that would be used if the rule fails. Conditions are used for specific types of expressions and each has specific options for results available as follows: + **Entry** - The conditions for making checks that, if met, allow entry to a stage. Rules are engaged with the following result options: **Fail** or **Skip** + **On Failure** - The conditions for making checks for the stage when it fails. Rules are engaged with the following result option: **Rollback** + **On Success** - The conditions for making checks for the stage when it succeeds. Rules are engaged with the following result options: **Rollback** or **Fail** The following diagram shows an example flow for the Entry condition type in CodePipeline. Conditions answer the question, What should happen if the condition is not met, meaning any rule fails? In the following flow, an Entry condition is configured with a LambdaInvoke rule and a `CloudWatchAlarm` rule. If the rule fails, then the configured result, such as Fail, is engaged. ![\[An example of the Entry condition type with two rules configured, a LambdaInvoke rule and a CloudWatchAlarm rule.\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/conditions-overview-entry.png) The following diagram shows an example flow for the On Failure condition type in CodePipeline. Conditions answer the question, What should happen if the condition is met, meaning the rules all succeed their checks? In the following flow, an On Failure condition is configured with a LambdaInvoke rule and a `CloudWatchAlarm` rule. If the rule succeeds, then the configured result, such as Fail, is engaged. ![\[An example of the On Failure condition type with two rules configured, a Lambda rule and a CloudWatchAlarm rule.\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/conditions-overview-onfailure.png) The following diagram shows an example flow for the On Success condition type in CodePipeline. Conditions answer the question, What should happen if the condition is met, meaning the rules all succeed their checks? In the following flow, an On Success condition is configured with a `LambdaInvoke` rule and a `CloudWatchAlarm` rule. If the rule succeeds, then the configured result, such as Fail, is engaged. ![\[An example of the On Success condition type with two rules configured, a Lambda rule and a CloudWatchAlarm rule.\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/conditions-overview-onsuccess.png) ## Rules for stage conditions When you configure stage conditions, you select from pre-defined rules and specify the results for the rule. A condition state will be Failed if any of the rules in the condition are failed and Succeeded if all the rules succeed. How criteria are met for conditions for On Failure and On Success depends on the type of rule. The following are managed rules that you can add to stage conditions. + Conditions can use the **Commands** rule to specify commands to meet the rule criteria for conditions. For more information about this rule, see [Commands](rule-reference-Commands.md). + Conditions can use the **AWS DeploymentWindow** rule to specify approved deployment times for allowing a deployment. The criteria for the rule will be measured with a provided cron expression for a deployment window. The rule succeeds when the date and time in the deployment window meet the criteria in the cron expression for the rule. For more information about this rule, see [DeploymentWindow](rule-reference-DeploymentWindow.md). + Conditions can use the **AWS Lambda** rule to check for error states returned from configured Lambda functions. The rule is met when the check receives the Lambda function result. An error from the Lambda function meets the criteria for On Failure conditions. For more information about this rule, see [LambdaInvoke](rule-reference-LambdaInvoke.md). + Conditions can use the **AWS CloudWatchAlarm** rule to check for alarms configured from CloudWatch events. The rule is met when the check returns an alarm state of OK, ALARM, or INSUFF\$1DATA. For On Success conditions, OK and INSUFFICIENT\$1DATA meet the criteria. ALARM meets the criteria for On Failure conditions. For more information about this rule, see [CloudWatchAlarm](rule-reference-CloudWatchAlarm.md). + Conditions can use the **VariableCheck** rule to create a condition where the output variable is checked against a provided expression. The rule passes the check when the variable value meets the rule criteria, such as the value being equal or greater than a specified output variable. For more information about this rule, see [VariableCheck](rule-reference-VariableCheck.md). # Pipeline types CodePipeline provides the following pipeline types, which differ in characteristics and price, so that you can tailor your pipeline features and cost to the needs of your applications. + V1 type pipelines have a JSON structure that contains standard pipeline, stage, and action-level parameters. + V2 type pipelines have the same structure as a V1 type, along with additional parameters for release safety and trigger configuration. For information about pricing for CodePipeline, see [Pricing](https://aws.amazon.com/codepipeline/pricing/). See the [CodePipeline pipeline structure reference](reference-pipeline-structure.md) page for details about parameters in each pipeline type. For information about which type of pipeline to choose, see [What type of pipeline is right for me?](pipeline-types-planning.md). # What type of pipeline is right for me? The pipeline type is determined by the set of characteristics and features supported by each pipeline version. The following is a summary of the use cases and characteristics available for each type of pipeline. **** | | V1 type | V2 type | Characteristics | | | | --- | --- | --- | --- | --- | --- | | Use cases | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/pipeline-types-planning.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/pipeline-types-planning.html) | | [Action-level variables](https://docs.aws.amazon.com/codepipeline/latest/userguide/reference-variables.html) | Supported | Supported | | [PARALLEL execution mode](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html#concepts-how-it-works-executions-parallel) | Not supported | Supported | | [Pipeline-level variables](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-pipeline-variables.html) | Not supported | Supported | | [QUEUED execution mode](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html#concepts-how-it-works-executions-queued) | Not supported | Supported | | [Rollback for pipeline stages](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-rollback.html) | Not supported | Supported | | [Source revision overrides](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-trigger-source-overrides.html) | Not supported | Supported | | [Stage conditions](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-conditions.html) | Not supported | Supported | | [Triggers and filtering Git tags, pull requests, branches, or file paths](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-filter.html) | Not supported | Supported | | [The Commands action](https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-Commands.html) | Not supported | Supported | | [ Creating Entry conditions with Skip result](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-conditions.html#stage-conditions-entry-skip) | Not supported | Supported | | [Configure a stage for automatic retry on failure](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-retry.html#stage-retry-auto) | Not supported | Supported | For information about pricing for CodePipeline, see [Pricing](https://aws.amazon.com/codepipeline/pricing/). You can create and run a Python script to help you analyze the potential cost of moving a V1 type pipeline to a V2 type pipeline. **Note** The sample script below is intended for demonstration and evaluation purposes only. It is not a quote tool and does not guarantee the cost for your actual use of a V2 type pipeline, and it does not include any taxes that might apply. For information about pricing for CodePipeline, see [Pricing](https://aws.amazon.com/codepipeline/pricing/). **To create and run a script to help you evaluate the cost of moving a V1 type pipeline to a V2 type pipeline** 1. Download and install python. 1. Open a terminal window. Run the following command to create a new python script named **PipelineCostAnalyzer.py**. ``` vi PipelineCostAnalyzer.py ``` 1. Copy and paste the following code into the **PipelineCostAnalyzer.py** script. ``` import boto3 import sys import math from datetime import datetime, timedelta, timezone if len(sys.argv) < 3: raise Exception("Please provide region name and pipeline name as arguments. Example usage: python PipelineCostAnalyzer.py us-east-1 MyPipeline") session = boto3.Session(profile_name='default', region_name=sys.argv[1]) pipeline = sys.argv[2] codepipeline = session.client('codepipeline') def analyze_cost_in_v2(pipeline_name): if codepipeline.get_pipeline(name=pipeline)['pipeline']['pipelineType'] == 'V2': raise Exception("Provided pipeline is already of type V2.") total_action_executions = 0 total_blling_action_executions = 0 total_action_execution_minutes = 0 cost = 0.0 hasNextToken = True nextToken = "" while hasNextToken: if nextToken=="": response = codepipeline.list_action_executions(pipelineName=pipeline_name) else: response = codepipeline.list_action_executions(pipelineName=pipeline_name, nextToken=nextToken) if 'nextToken' in response: nextToken = response['nextToken'] else: hasNextToken= False for action_execution in response['actionExecutionDetails']: start_time = action_execution['startTime'] end_time = action_execution['lastUpdateTime'] if (start_time < (datetime.now(timezone.utc) - timedelta(days=30))): hasNextToken= False continue total_action_executions += 1 if (action_execution['status'] in ['Succeeded', 'Failed', 'Stopped']): action_owner = action_execution['input']['actionTypeId']['owner'] action_category = action_execution['input']['actionTypeId']['category'] if (action_owner == 'Custom' or (action_owner == 'AWS' and action_category == 'Approval')): continue total_blling_action_executions += 1 action_execution_minutes = (end_time - start_time).total_seconds()/60 action_execution_cost = math.ceil(action_execution_minutes) * 0.002 total_action_execution_minutes += action_execution_minutes cost = round(cost + action_execution_cost, 2) print ("{:<40}".format('Activity in last 30 days:')) print ("| {:<40} | {:<10}".format('___________________________________', '__________________')) print ("| {:<40} | {:<10}".format('Total action executions:', total_action_executions)) print ("| {:<40} | {:<10}".format('Total billing action executions:', total_blling_action_executions)) print ("| {:<40} | {:<10}".format('Total billing action execution minutes:', round(total_action_execution_minutes, 2))) print ("| {:<40} | {:<10}".format('Cost of moving to V2 in $:', cost - 1)) analyze_cost_in_v2(pipeline) ``` 1. From the terminal or command prompt, change directories to where you created the analyzer script. From that directory, run the following command, where *region* is the AWS Region where you created the V1 pipelines you want to analyze. You can also optionally evaluate a specific pipeline by providing its name: ``` python3 PipelineCostAnalyzer.py region --pipelineName ``` For example, run the following command to run the python script named **PipelineCostAnalyzer.py**. In this example, the Region is `us-west-2`. ``` python3 PipelineCostAnalyzer.py us-west-2 ``` **Note** This script will analyze all V1 pipelines in the specified AWS Region unless you specify a specific pipeline name. 1. In the following sample output from the script, we can see the list of action executions, the list of action executions that were eligible for billing, the total runtime of these action executions, and the estimated cost of these actions as performed in a V2 pipeline. ``` Activity in last 30 days: | ___________________________________ | __________________ | Total action executions: | 9 | Total billing action executions: | 9 | Total billing action execution minutes: | 5.59 | Cost of moving to V2 in $: | -0.76 ``` In this example, the negative value in the last row represents the estimated amount that might be saved by moving to V2 type pipelines. **Note** The script output and related examples that show costs and other information are estimates only. They are intended for demonstration and evaluation purposes only and do not guarantee any actual savings. For information about pricing for CodePipeline, see [Pricing](https://aws.amazon.com/codepipeline/pricing/).