# Start a pipeline in CodePipeline
Each pipeline execution can be started based on a different trigger. Each pipeline execution can have a different type of trigger, depending on how the pipeline is started. The trigger type for each execution is shown in the execution history for a pipeline. Trigger types can depend on the source action provider as follows:
**Note**
You cannot specify more than one trigger per source action.
+ **Pipeline creation**: When a pipeline is created, a pipeline execution starts automatically. This is the `CreatePipeline` trigger type in the **Execution history**.
+ **Changes on revised objects**: This category represents the `PutActionRevision` trigger type in the **Execution history**.
+ **Change detection on branch and commit for a code push**: This category represents the `CloudWatchEvent` trigger type in the **Execution history**. When a change is detected to a source commit and branch in the source repository, your pipeline starts. This trigger type uses automated change detection. The source action providers that use this trigger type are S3 and CodeCommit. This type is also used for a schedule that starts your pipeline. See [Start a pipeline on a schedule](pipelines-trigger-source-schedule.md).
+ **Polling for source changes**: This category represents the `PollForSourceChanges` trigger type in the **Execution history**. When a change is detected to a source commit and branch in the source repository through polling, your pipeline starts. This trigger type is not recommended and should be migrated to use automated change detection. The source action providers that use this trigger type are S3 and CodeCommit.
+ **Webhook events for third-party sources**: This category represents the `Webhook` trigger type in the **Execution history**. When a change is detected by a webhook event, your pipeline starts. This trigger type uses automated change detection. The source action providers that use this trigger type are connections configured for code push (Bitbucket Cloud, GitHub, GitHub Enterprise Server, GitLab.com, and GitLab self-managed).
+ **WebhookV2 events for third-party sources**: This category represents the `WebhookV2` trigger type in the **Execution history**. This type is for executions that are triggered based on triggers defined in the pipeline definition. When a release with a specified Git tag is detected, your pipeline starts. You can use Git tags to mark a commit with a name or other identifier that helps other repository users understand its importance. You can also use Git tags to identify a particular commit in the history of a repository. This trigger type disables automated change detection. The source action providers that use this trigger type are connections configured for Git tags (Bitbucket Cloud, GitHub, GitHub Enterprise Server, and GitLab.com).
+ **Manually starting a pipeline**: This category represents the `StartPipelineExecution` trigger type in the **Execution history**. You can use the console or the AWS CLI to start a pipeline manually. For information, see [Start a pipeline manually](pipelines-rerun-manually.md).
+ **RollbackStage**: This category represents the `RollbackStage` trigger type in the **Execution history**. You can use the console or the AWS CLI to roll back a stage manually or automatically. For information, see [Configuring stage rollback](stage-rollback.md).
When you add a source action to your pipeline that uses automated change detection trigger types, the actions work with additional resources. Creating each source action is detailed in separate sections due to these additional resources for change detection. For details about each source provider and the change detection methods required for automated change detection, see [Source actions and change detection methods](change-detection-methods.md).
**Topics**
+ [
# Start a pipeline manually
](pipelines-rerun-manually.md)
+ [
# Start a pipeline on a schedule
](pipelines-trigger-source-schedule.md)
+ [
# Start a pipeline with a source revision override
](pipelines-trigger-source-overrides.md)
# Start a pipeline manually
By default, a pipeline starts automatically when it is created and any time a change is made in a source repository. However, you might want to rerun the most recent revision through the pipeline a second time. You can use the CodePipeline console or the AWS CLI and **start-pipeline-execution** command to manually rerun the most recent revision through your pipeline.
**Topics**
+ [
## Start a pipeline manually (console)
](#pipelines-rerun-manually-console)
+ [
## Start a pipeline manually (CLI)
](#pipelines-rerun-manually-cli)
## Start a pipeline manually (console)
**To manually start a pipeline and run the most recent revision through a pipeline**
1. Sign in to the AWS Management Console and open the CodePipeline console at [http://console.aws.amazon.com/codesuite/codepipeline/home](http://console.aws.amazon.com/codesuite/codepipeline/home).
1. In **Name**, choose the name of the pipeline you want to start.
1. On the pipeline details page, choose **Release change**. If the pipeline is configured to pass parameters (pipeline variables), then choosing **Release change** opens the **Release change** window. In **Pipeline variables**, in the field or fields for the variables at the pipeline level, enter the value or values you want to pass for this pipeline execution. For more information, see [Variables reference](reference-variables.md).
This starts the most recent revision available in each source location specified in a source action through the pipeline.
## Start a pipeline manually (CLI)
**To manually start a pipeline and run the most recent version of an artifact through a pipeline**
1. Open a terminal (Linux, macOS, or Unix) or command prompt (Windows) and use the AWS CLI to run the **start-pipeline-execution** command, specifying the name of the pipeline you want to start. For example, to start running the last change through a pipeline named *MyFirstPipeline*:
```
aws codepipeline start-pipeline-execution --name MyFirstPipeline
```
To start a pipeline where variables are configured at the pipeline level, use the **start-pipeline-execution** command with the optional **--variables** argument to start the pipeline and add the variables that will be used in the execution. For example, to add a variable `var1` with a value of `1`, use the following command:
```
aws codepipeline start-pipeline-execution --name MyFirstPipeline --variables name=var1,value=1
```
1. To verify success, view the returned object. This command returns an execution ID, similar to the following:
```
{
"pipelineExecutionId": "c53dbd42-This-Is-An-Example"
}
```
**Note**
After you have started the pipeline, you can monitor its progress in the CodePipeline console or by running the **get-pipeline-state** command. For more information, see [View pipelines (console)](pipelines-view-console.md) and [View pipeline details and history (CLI)](pipelines-view-cli.md).
# Start a pipeline on a schedule
You can set up a rule in EventBridge to start a pipeline on a schedule.
## Create an EventBridge rule that schedules your pipeline to start (console)
**To create an EventBridge rule with a schedule as the event source**
1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. In the navigation pane, choose **Rules**.
1. Choose **Create rule**, and then under **Rule detail**, choose **Schedule**.
1. Set up the schedule using a fixed rate or expression. For information, see [Schedule Expression for Rules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html).
1. In **Targets**, choose **CodePipeline**.
1. Enter the pipeline ARN for the pipeline execution for this schedule.
**Note**
You can find the pipeline ARN under **Settings** in the console. See [View the pipeline ARN and service role ARN (console)](pipelines-settings-console.md).
1. Choose one of the following to create or specify an IAM service role that gives EventBridge permissions to invoke the target associated with your EventBridge rule (in this case, the target is CodePipeline).
+ Choose **Create a new role for this specific resource** to create a service role that grants EventBridge permissions to start your pipeline executions.
+ Choose **Use existing role** to enter a service role that grants EventBridge permissions to start your pipeline executions.
1. Choose **Configure details**.
1. On the **Configure rule details** page, enter a name and description for the rule, and then choose **State** to enable the rule.
1. If you're satisfied with the rule, choose **Create rule**.
## Create an EventBridge rule that schedules your pipeline to start (CLI)
To use the AWS CLI to create a rule, call the **put-rule** command, specifying:
+ A name that uniquely identifies the rule you are creating. This name must be unique across all of the pipelines you create with CodePipeline associated with your AWS account.
+ The schedule expression for the rule.
**To create an EventBridge rule with a schedule as the event source**
1. Call the **put-rule** command and include the `--name `and `--schedule-expression` parameters.
Examples:
The following sample command uses **--schedule-expression** to create a rule called `MyRule2` that filters EventBridge on a schedule.
```
aws events put-rule --schedule-expression 'cron(15 10 ? * 6L 2002-2005)' --name MyRule2
```
1. To add CodePipeline as a target, call the **put-targets** command and include the following parameters:
+ The `--rule` parameter is used with the `rule_name` you created by using **put-rule**.
+ The `--targets` parameter is used with the list `Id` of the target in the list of targets and the `ARN` of the target pipeline.
The following sample command specifies that for the rule called `MyCodeCommitRepoRule`, the target `Id` is composed of the number one, indicating that in a list of targets for the rule, this is target 1. The sample command also specifies an example `ARN` for the pipeline. The pipeline starts when something changes in the repository.
```
aws events put-targets --rule MyCodeCommitRepoRule --targets Id=1,Arn=arn:aws:codepipeline:us-west-2:80398EXAMPLE:TestPipeline
```
1. Grant permissions for EventBridge to use CodePipeline to invoke the rule. For more information, see [Using resource-based policies for Amazon EventBridge](http://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html).
1. Use the following sample to create the trust policy to allow EventBridge to assume the service role. Name it `trustpolicyforEB.json`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. Use the following command to create the `Role-for-MyRule` role and attach the trust policy.
```
aws iam create-role --role-name Role-for-MyRule --assume-role-policy-document file://trustpolicyforEB.json
```
1. Create the permissions policy JSON as shown in this sample for the pipeline named `MyFirstPipeline`. Name the permissions policy `permissionspolicyforEB.json`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:StartPipelineExecution"
],
"Resource": [
"arn:aws:codepipeline:us-west-2:111122223333:MyFirstPipeline"
]
}
]
}
```
------
1. Use the following command to attach the new `CodePipeline-Permissions-Policy-for-EB` permissions policy to the `Role-for-MyRule` role you created.
```
aws iam put-role-policy --role-name Role-for-MyRule --policy-name CodePipeline-Permissions-Policy-For-EB --policy-document file://permissionspolicyforCWE.json
```
# Start a pipeline with a source revision override
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.
**Note**
You can also create a source override using input transform entry to use the `revisionValue` in EventBridge for your pipeline event, where the `revisionValue` is derived from the source event variable for your object key, commit, or image ID. For more information, see the optional step for input transform entry included in the procedures under [Amazon ECR source actions and EventBridge resources](create-cwe-ecr-source.md), [Connecting to Amazon S3 source actions with a source enabled for events](create-S3-source-events.md), or [CodeCommit source actions and EventBridge](triggering.md).
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).
**Topics**
+ [
## Start a pipeline with a source revision override (console)
](#pipelines-trigger-source-overrides-console)
+ [
## Start a pipeline with a source revision override (CLI)
](#pipelines-trigger-source-overrides-cli)
## Start a pipeline with a source revision override (console)
**To manually start a pipeline and run the most recent revision through a pipeline**
1. Sign in to the AWS Management Console and open the CodePipeline console at [http://console.aws.amazon.com/codesuite/codepipeline/home](http://console.aws.amazon.com/codesuite/codepipeline/home).
1. In **Name**, choose the name of the pipeline you want to start.
1. On the pipeline details page, choose **Release change**. Choosing **Release change** opens the **Release change** window. For **Source revision override**, choose the arrow to expand the field. In **Source**, enter the source revision ID. For example, if your pipeline has a CodeCommit source, choose the commit ID from the field that you want to use.
![\[An example of the overrides screen in CodePipeline.\]](http://docs.aws.amazon.com/codepipeline/latest/userguide/images/overrides.png)
## Start a pipeline with a source revision override (CLI)
**To manually start a pipeline and run the specified source revision ID for an artifact through a pipeline**
1. Open a terminal (Linux, macOS, or Unix) or command prompt (Windows) and use the AWS CLI to run the **start-pipeline-execution** command, specifying the name of the pipeline you want to start. You also use the **--source-revisions** argument to provide the source revision ID. The source revision is made up of the actionName, revisionType, and revisionValue. Valid revisionType values are `COMMIT_ID | IMAGE_DIGEST | S3_OBJECT_VERSION_ID | S3_OBJECT_KEY`.
In the following example, to start running the specified change through a pipeline named **codecommit-pipeline**, the following command species a source action name of Source, a revision type of `COMMIT_ID`, and a commit ID of `78a25c18755ccac3f2a9eec099dEXAMPLE`.
```
aws codepipeline start-pipeline-execution --name codecommit-pipeline --source-revisions actionName=Source,revisionType=COMMIT_ID,revisionValue=78a25c18755ccac3f2a9eec099dEXAMPLE --region us-west-1
```
1. To verify success, view the returned object. This command returns an execution ID, similar to the following:
```
{
"pipelineExecutionId": "c53dbd42-This-Is-An-Example"
}
```
**Note**
After you have started the pipeline, you can monitor its progress in the CodePipeline console or by running the **get-pipeline-state** command. For more information, see [View pipelines (console)](pipelines-view-console.md) and [View pipeline details and history (CLI)](pipelines-view-cli.md).