翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# CodePipeline パイプライン構造リファレンス
CodePipeline を使用して、アプリケーションのソースコードを構築、テスト、デプロイするタスクの実行手順が自動化された CI/CD パイプラインを構築できます。このリファレンスセクションでは、パイプラインの JSON 構造とパラメータについて詳しく説明します。パイプラインの使用方法を説明する概念の大まかなリストについては、「[CodePipeline の概念 ](concepts.md)」を参照してください。
+ パイプラインを作成するときは、ソースコードを含むとともに、ソースコードの変更をコミットしたときにパイプラインを開始する S3 バケット、CodeCommit リポジトリ、Bitbucket リポジトリ、GitHub リポジトリなどの利用可能なプロバイダーとソースアクションを選択します。このリファレンスセクションでは、パイプラインで使用可能なソースに関するリファレンス情報を提供します。ソースアクションの操作の詳細については、「[CodePipeline でパイプラインを編集する](pipelines-about-starting.md)」を参照してください。
+ パイプラインの実行時に自動的に含めるテスト、ビルド、デプロイのアクションとプロバイダーを選択できます。このリファレンスセクションでは、使用可能なアクションと、それらがパイプライン JSON にどのように適合するかに関するリファレンス情報を提供します。
+ 完成したパイプラインは、ソースステージと、アプリケーションをデプロイしてテストするアクションを設定する追加のステージで構成されます。アプリケーションをデプロイする DevOps パイプラインの概念的な例については、「[DevOps パイプラインの例](concepts-devops-example.md)」を参照してください。
デフォルトでは、 で正常に作成したパイプライン AWS CodePipeline の構造は有効です。ただし、JSON ファイルを手動で作成または編集してパイプラインを作成したり、 からパイプラインを更新したりすると AWS CLI、無効な構造が誤って作成される可能性があります。次のリファレンスは、パイプライン構造の要件や、問題のトラブルシューティング方法を理解するのに役立ちます。すべてのパイプラインに適用される [AWS の CodePipeline 中のクォータ](limits.md) の制約を参照してください。
以下のセクションでは、高レベルのパラメータと、パイプライン構造におけるこれらのパラメータの位置について説明します。パイプライン構造の要件は、以下のパイプラインコンポーネントタイプごとに各セクションで詳しく説明しています。
+ [パイプライン宣言](pipeline-requirements.md)のフィールドリファレンス
+ [ステージ宣言](stage-requirements.md)のフィールドリファレンス
+ [アクションの宣言](action-requirements.md)のフィールドリファレンス
+ アクションタイプ別の[CodePipeline の有効なアクションプロバイダー](actions-valid-providers.md)のリスト
+ [`PollForSourceChanges` パラメータの有効な設定](PollForSourceChanges-defaults.md)のリファレンス
+ [アクションタイプ別の有効な入力/出力アーティファクトの数](reference-action-artifacts.md)のリファレンス
+ [プロバイダータイプ別の有効な設定パラメータ](structure-configuration-examples.md)へのリンクのリスト
詳細については、「*CodePipeline API ガイド*」の「[PipelineDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineDeclaration.html)」オブジェクトを参照してください。
次のパイプラインコンソールビューの例は、new-github という名前のパイプライン、ステージ (`Source`、`manual`、`Build`)、GitHub (GitHub アプリ経由) からのアクション、手動承認、CodeBuild アクションプロバイダーを示しています。
![\[CodePipeline コンソールのパイプラインビューの例。\]](http://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/images/pipeline-console-view.png)
パイプライン編集モードをコンソール図で表示すると、次の例に示すように、ソースの上書き、トリガー、アクションを編集できます。
![\[CodePipeline コンソールのパイプライン編集モードの例。\]](http://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/images/pipeline-console-view-edit.png)
**Topics**
+ [パイプライン宣言](pipeline-requirements.md)
+ [ステージ宣言](stage-requirements.md)
+ [アクションの宣言](action-requirements.md)
+ [CodePipeline の有効なアクションプロバイダー](actions-valid-providers.md)
+ [`PollForSourceChanges` パラメータの有効な設定](PollForSourceChanges-defaults.md)
+ [アクションタイプ別の有効な入力/出力アーティファクトの数](reference-action-artifacts.md)
+ [プロバイダータイプ別の有効な設定パラメータ](structure-configuration-examples.md)
# パイプライン宣言
パイプラインレベルおよびメタデータレベルのパイプラインには、以下のパラメータと構文を含む基本構造があります。パイプラインパラメータは、パイプラインで実行するアクションとステージの構造を表します。
詳細については、「*CodePipeline API ガイド*」の「[PipelineDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineDeclaration.html)」オブジェクトを参照してください。
次の例は、V2 タイプのパイプラインについて、パイプラインレベルおよびメタデータレベルのパイプライン構造を JSON と YAML の両方で示しています。
------
#### [ YAML ]
```
pipeline:
name: MyPipeline
roleArn: >-
arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline
artifactStore:
type: S3
location: amzn-s3-demo-bucket
stages:
...
version: 6
executionMode: SUPERSEDED
pipelineType: V2
variables:
- name: MyVariable
defaultValue: '1'
triggers:
- providerType: CodeStarSourceConnection
gitConfiguration:
sourceActionName: Source
push:
- branches:
includes:
- main
excludes:
- feature-branch
pullRequest:
- events:
- CLOSED
branches:
includes:
- main*
metadata:
pipelineArn: 'arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline'
created: '2019-12-12T06:49:02.733000+00:00'
updated: '2020-09-10T06:34:07.447000+00:00'
pollingDisabledAt: '2020-09-10T06:34:07.447000\$100:00'
```
------
#### [ JSON ]
```
{
"pipeline": {
"name": "MyPipeline",
"roleArn": "arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline",
"artifactStore": {
"type": "S3",
"location": "amzn-s3-demo-bucket"
},
"stages": {
...
},
"version": 6,
"executionMode": "SUPERSEDED",
"pipelineType": "V2",
"variables": [
{
"name": "MyVariable",
"defaultValue": "1"
}
],
"triggers": [
{
"providerType": "CodeStarSourceConnection",
"gitConfiguration": {
"sourceActionName": "Source",
"push": [
{
"branches": {
"includes": [
"main"
],
"excludes": [
"feature-branch"
]
}
}
],
"pullRequest": [
{
"events": [
"CLOSED"
],
"branches": {
"includes": [
"main*"
]
}
}
]
}
}
]
},
"metadata": {
"pipelineArn": "arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline",
"created": "2019-12-12T06:49:02.733000+00:00",
"updated": "2020-09-10T06:34:07.447000+00:00",
"pollingDisabledAt": "2020-09-10T06:34:07.447000+00:00"
}
}
```
------
## `name`
パイプラインの名前。パイプラインを編集または更新する場合、パイプライン名は変更できません。
**注記**
既存のパイプラインの名前を変更するには、CLI `get-pipeline` コマンドを使用して、パイプライン構造を含む JSON ファイルを作成します。次に、CLI `create-pipeline` コマンドを使用してその構造を持つ新しいパイプラインを作成し、新しい名前を付けます。
## `roleArn`
CodePipeline サービスロールの IAM ARN (arn:aws:iam::80398EXAMPLE:role/CodePipeline\$1Service\$1Role など)。
コンソールを使用して、JSON 構造ではなくパイプラインサービスロール ARN を表示するには、コンソールでパイプラインを選択し、**[設定]** を選択します。**[全般]** タブに、**[サービスロール ARN]** フィールドが表示されます。
## `artifactStore` または `artifactStores`
`artifactStore` フィールドには、同じ AWS リージョン内のすべてのアクションを持つパイプラインのアーティファクトバケットタイプと場所が含まれます。パイプラインとは異なるリージョンにアクションを追加すると、`artifactStores`マッピングを使用して、アクションが実行される各 AWS リージョンのアーティファクトバケットが一覧表示されます。パイプラインを作成または編集する場合は、パイプラインリージョンにアーティファクトバケットが必要であり、アクションを実行する予定のリージョンごとに 1 つのアーティファクトバケットが必要です。
**注記**
パイプライン構造では、パイプラインに `artifactStore` または `artifactStores` のどちらかを含める必要がありますが、両方を使用することはできません。パイプラインでクロスリージョンアクションを作成する場合は、`artifactStores` を使用する必要があります。
以下の例では、`artifactStores` パラメータを使用するクロスリージョンアクションを含むパイプラインの基本構造を示しています。
```
"pipeline": {
"name": "YourPipelineName",
"roleArn": "CodePipeline_Service_Role",
"artifactStores": {
"us-east-1": {
"type": "S3",
"location": "S3 artifact bucket name, such as amzn-s3-demo-bucket"
},
"us-west-2": {
"type": "S3",
"location": "S3 artifact bucket name, such as amzn-s3-demo-bucket"
}
},
"stages": [
{
...
```
### `type`
Amazon S3 として指定した、アーティファクトバケットの場所タイプ。
### `location`
コンソールを使用してパイプラインを初めて作成するときに自動的に生成される Amazon S3 バケットの名前 (codepipeline-us-east-2-1234567890 など)、またはこの目的のためにプロビジョニングする任意の Amazon S3 バケットの名前。
## `stages`
このパラメータには、パイプラインの各ステージの名前が含まれます。パイプライン構造のステージレベルのパラメータと構文の詳細については、「*CodePipeline API ガイド*」の「[StageDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageDeclaration.html)」オブジェクトを参照してください。
ステージのパイプライン構造には、以下の要件があります。
+ パイプラインには、少なくとも 2 つのステージが含まれている必要がある
+ パイプラインの最初のステージには、少なくとも 1 つのソースアクションが含まれている必要がある ソースアクションのみを含めることができる
+ ソースアクションを含むことができるのは、パイプラインの最初のステージのみである
+ 各パイプラインの少なくとも 1 つのステージに、ソースアクション以外のアクションが含まれている必要がある
+ パイプライン内のすべてのステージ名は一意である必要がある
+ ステージ名は、CodePipeline コンソール内で編集することはできません。を使用してステージ名を編集し AWS CLI、ステージに 1 つ以上のシークレットパラメータ (OAuth トークンなど) を含むアクションが含まれている場合、それらのシークレットパラメータの値は保持されません。パラメータ値 ( AWS CLIよって返される JSON で、4 つのアスタリスクでマスクされている) は手動で入力し、JSON 構造に含める必要があります。
**重要**
30 日以上非アクティブなパイプラインでは、パイプラインのポーリングが無効になります。詳細については、パイプイライン構造リファレンスの「[pollingDisabledAt](#metadata.pollingDisabledAt)」を参照してください。パイプラインをポーリングからイベントベースの変更検出に移行する手順については、「[変更検出方法](change-detection-methods.md)」を参照してください。
## `version`
パイプラインのバージョン番号は自動的に生成され、パイプラインを更新するたびに更新されます。
## `executionMode`
パイプライン実行モードを設定すると、キュー、優先、並列モードでの実行など、連続した実行のパイプライン動作を指定できます。詳細については、「[パイプライン実行モードを設定または変更する](execution-modes.md)」を参照してください。
**重要**
PARALLEL モードのパイプラインでは、ステージのロールバックは使用できません。同様に、ロールバック結果タイプの障害条件を PARALLEL モードのパイプラインに追加することはできません。
## `pipelineType`
パイプラインタイプは、V2 タイプのパイプラインなど、パイプラインで利用可能な構造と機能を指定します。詳細については、「[パイプラインのタイプ](pipeline-types.md)」を参照してください。
## `variables`
パイプラインレベルの変数は、パイプラインの作成時に定義され、パイプラインの実行時に解決されます。詳細については、「[変数リファレンス](reference-variables.md)」を参照してください。パイプラインの実行時に渡されるパイプラインレベルの変数のチュートリアルについては、「[チュートリアル: パイプラインレベルの変数を使用する](tutorials-pipeline-variables.md)」を参照してください。
## `triggers`
トリガーを使用すると、特定のブランチやプルリクエストの変更を検出したときなど、特定のイベントタイプやフィルタリングされたイベントタイプに応じて開始するようにパイプラインを設定できます。トリガーは、GitHub、Bitbucket、GitLab など、CodePipeline の `CodeStarSourceConnection` アクションを実行する接続を使用するソースアクションに対して設定できます。接続を使用するソースアクションの詳細については、「[CodeConnections を使用してサードパーティのソースプロバイダーを追加する](pipelines-connections.md)」を参照してください。
詳細とより具体的な例については、「[トリガーとフィルタリングを使用してパイプラインを自動的に開始する](pipelines-triggers.md)」を参照してください。
フィルタリングでは、「[構文での glob パターンの使用](syntax-glob.md)」で詳述しているように、正規表現パターンを glob 形式でサポートしています。
**注記**
CodeCommit および S3 ソースアクションには、設定済みの変更検出リソース (EventBridge ルール)、またはオプションを使用してソースの変更をリポジトリにポーリングする必要があります。Bitbucket、GitHub、または GitHub Enterprise Server のソースアクションを持つパイプラインの場合、ウェブフックを設定したり、デフォルトでポーリングを行う必要はありません。接続アクションは、変更検出を管理します。
**重要**
30 日以上非アクティブなパイプラインでは、パイプラインのポーリングが無効になります。詳細については、パイプイライン構造リファレンスの「[pollingDisabledAt](#metadata.pollingDisabledAt)」を参照してください。パイプラインをポーリングからイベントベースの変更検出に移行する手順については、「[変更検出方法](change-detection-methods.md)」を参照してください。
### `gitConfiguration` フィールド
イベントタイプ、ブランチ、ファイルパス、タグ、プルリクエストイベントでフィルタリングするためのパラメータなど、トリガーの Git 設定。
JSON 構造内のフィールドの定義は以下のとおりです。
+ `sourceActionName`: Git 設定のパイプラインソースアクションの名前。
+ `push`: フィルタリングを含むプッシュイベント。これらのイベントは、異なるプッシュフィルター間では OR 演算を使用し、フィルター内では AND 演算を使用します。
+ `branches`: フィルタリングするブランチ。ブランチは、[含める] と [除外する] の間で AND 演算を使用します。
+ `includes`: 含めるブランチをフィルタリングするパターン。[含める] では OR 演算を使用します。
+ `excludes`: 除外するブランチをフィルタリングするパターン。[除外する] では OR 演算を使用します。
+ `filePaths`: フィルタリングするファイルパス名。
+ `includes`: 含めるファイルパスをフィルタリングするパターン。[含める] では OR 演算を使用します。
+ `excludes`: 除外するファイルパスをフィルタリングするパターン。[除外する] では OR 演算を使用します。
+ `tags`: フィルタリングするタグ名。
+ `includes`: 含めるタグをフィルタリングするパターン。[含める] では OR 演算を使用します。
+ `excludes`: 除外するタグをフィルタリングするパターン。[除外する] では OR 演算を使用します。
+ `pullRequest`: プルリクエストイベントとプルリクエストフィルターのフィルタリングを含むプルリクエストイベント。
+ `events`: オープン、更新、またはクローズしたプルリクエストイベントを指定どおりにフィルタリングします。
+ `branches`: フィルタリングするブランチ。ブランチは、[含める] と [除外する] の間で AND 演算を使用します。
+ `includes`: 含めるブランチをフィルタリングするパターン。[含める] では OR 演算を使用します。
+ `excludes`: 除外するブランチをフィルタリングするパターン。[除外する] では OR 演算を使用します。
+ `filePaths`: フィルタリングするファイルパス名。
+ `includes`: 含めるファイルパスをフィルタリングするパターン。[含める] では OR 演算を使用します。
+ `excludes`: 除外するファイルパスをフィルタリングするパターン。[除外する] では OR 演算を使用します。
プッシュおよびプルリクエストイベントタイプのトリガー設定の例を次に示します。
```
"triggers": [
{
"provider": "Connection",
"gitConfiguration": {
"sourceActionName": "ApplicationSource",
"push": [
{
"filePaths": {
"includes": [
"projectA/**",
"common/**/*.js"
],
"excludes": [
"**/README.md",
"**/LICENSE",
"**/CONTRIBUTING.md"
]
},
"branches": {
"includes": [
"feature/**",
"release/**"
],
"excludes": [
"mainline"
]
},
"tags": {
"includes": [
"release-v0", "release-v1"
],
"excludes": [
"release-v2"
]
}
}
],
"pullRequest": [
{
"events": [
"CLOSED"
],
"branches": {
"includes": [
"feature/**",
"release/**"
],
"excludes": [
"mainline"
]
},
"filePaths": {
"includes": [
"projectA/**",
"common/**/*.js"
],
"excludes": [
"**/README.md",
"**/LICENSE",
"**/CONTRIBUTING.md"
]
}
}
]
}
}
],
```
### 包含および除外のイベントタイプ `push` フィールド
**プッシュ**イベントタイプの Git 設定フィールドレベルの包含および除外動作を次のリストに示します。
```
push (OR operation is used between push and pullRequest or multiples)
filePaths (AND operation is used between filePaths, branches, and tags)
includes (AND operation is used between includes and excludes)
**/FILE.md, **/FILE2 (OR operation is used between file path names)
excludes (AND operation is used between includes and excludes)
**/FILE.md, **/FILE2 (OR operation is used between file path names)
branches (AND operation is used between filePaths, branches, and tags)
includes (AND operation is used between includes and excludes)
BRANCH/**", "BRANCH2/** (OR operation is used between branch names)
excludes (AND operation is used between includes and excludes)
BRANCH/**", "BRANCH2/** (OR operation is used between branch names)
tags (AND operation is used between filePaths, branches, and tags)
includes (AND operation is used between includes and excludes)
TAG/**", "TAG2/** (OR operation is used between tag names)
excludes (AND operation is used between includes and excludes)
TAG/**", "TAG2/** (OR operation is used between tag names)
```
### 包含および除外のイベントタイプ `pull request` フィールド
**プルリクエスト**イベントタイプの Git 設定フィールドレベルの包含および除外動作を次のリストに示します。
```
pullRequest (OR operation is used between push and pullRequest or multiples)
events (AND operation is used between events, filePaths, and branches). Includes/excludes are N/A for pull request events.
filePaths (AND operation is used between events, filePaths, and branches)
includes (AND operation is used between includes and excludes)
**/FILE.md, **/FILE2 (OR operation is used between file path names)
excludes (AND operation is used between includes and excludes)
**/FILE.md, **/FILE2 (OR operation is used between file path names)
branches (AND operation is used between events, filePaths, and branches)
includes (AND operation is used between includes and excludes)
BRANCH/**", "BRANCH2/** (OR operation is used between branch names)
excludes (AND operation is used between includes and excludes)
BRANCH/**", "BRANCH2/** (OR operation is used between branch names)
```
## `metadata`
パイプラインメタデータフィールドはパイプライン構造とは異なり、編集することはできません。パイプラインを更新すると、`updated` メタデータフィールドの日付が自動的に変更されます。
### `pipelineArn`
パイプラインの Amazon リソースネーム (ARN)。
コンソールを使用して、JSON 構造ではなくパイプライン ARN を表示するには、コンソールでパイプラインを選択し、**[設定]** を選択します。**[全般]** タブに、**[パイプライン ARN]** フィールドが表示されます。
### `created`
パイプラインの作成日時。
### `updated`
パイプラインの最終更新日時。
### `pollingDisabledAt`
変更検出のポーリング用に設定されたパイプラインについて、ポーリングが無効になった日時。
30 日以上非アクティブなパイプラインでは、パイプラインのポーリングが無効になります。
+ 30 日間実行しない場合、非アクティブなパイプラインのポーリングは無効になります。
+ EventBridge、CodeStar Connections、またはウェブフックを使用するパイプラインは影響を受けません。
+ アクティブなパイプラインは影響を受けません。
詳細については、「*CodePipeline API ガイド*」の [PipelineMetadata](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineMetadata.html) オブジェクトの `pollingDisabledAt` パラメータを参照してください。パイプラインをポーリングからイベントベースの変更検出に移行する手順については、「[変更検出方法](change-detection-methods.md)」を参照してください。
# ステージ宣言
ステージレベルのパイプラインには、以下のパラメータと構文を含む基本構造があります。詳細については、「*CodePipeline API ガイド*」の「[StageDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageDeclaration.html)」オブジェクトを参照してください。
次の例は、ステージレベルのパイプライン構造を JSON と YAML の両方で示しています。この例には、`Source` および `Build` という 2 つのステージが含まれています。`onSuccess` の条件と `beforeEntry` の条件の 2 つも含まれています。
------
#### [ YAML ]
```
pipeline:
name: MyPipeline
roleArn: >-
arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline
artifactStore:
type: S3
location: amzn-s3-demo-bucket
stages:
- name: Source
actions:
- name: Source
...
- name: Build
actions:
- name: Build
...
onSuccess:
conditions:
- result: ROLLBACK
rules:
- name: DeploymentWindowRule
...
beforeEntry:
conditions:
- result: FAIL
rules:
- name: MyLambdaRule
...
version: 6
metadata:
pipelineArn: 'arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline'
created: '2019-12-12T06:49:02.733000+00:00'
updated: '2020-09-10T06:34:07.447000+00:00'
```
------
#### [ JSON ]
```
{
"pipeline": {
"name": "MyPipeline",
"roleArn": "arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline",
"artifactStore": {
"type": "S3",
"location": "amzn-s3-demo-bucket"
},
"stages": [
{
"name": "Source",
"actions": [
{
"name": "Source",
...
}
]
},
{
"name": "Build",
"actions": [
{
"name": "Build",
...
}
],
"onSuccess": {
"conditions": [
{
"result": "ROLLBACK",
"rules": [
{
"name": "DeploymentWindowRule",
...
}
]
}
]
},
"beforeEntry": {
"conditions": [
{
"result": "FAIL",
"rules": [
{
"name": "MyLambdaRule",
...
}
]
}
]
}
}
],
}
],
"version": 6
},
"metadata": {
"pipelineArn": "arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline",
"created": "2019-12-12T06:49:02.733000+00:00",
"updated": "2020-09-10T06:34:07.447000+00:00"
}
}
```
------
## `name`
ステージの名前。
## `actions`
アクションレベルのパイプラインには、以下のパラメータと構文を含む基本構造があります。パラメータと例を表示するには、「[アクションの宣言](action-requirements.md)」を参照してください。
## `conditions`
条件には、CodePipeline のルールのリストで使用できる 1 つ以上のルールが含まれます。条件内のすべてのルールが成功すると、条件は満たされます。条件が満たされない場合に、指定した結果が適用されるように、条件を設定できます。
以下のタイプの条件を設定できます。
+ `beforeEntry`
+ `onFailure`
+ `onSuccess`
詳細な説明と例については、[ステージの条件を設定する](stage-conditions.md) を参照してください。
## `rules`
各条件内には、一連の順序付けられたルールがあり、セットとしてまとめて評価されます。したがって、条件内の 1 つのルールが失敗すると、条件は失敗します。ルール条件は、パイプラインのランタイムに上書きできます。
利用可能なルールは、ルールリファレンスに記載しています。詳細については、「[ルール構造リファレンス](rule-reference.md)」でルール構造リファレンスを参照してください。
# アクションの宣言
アクションレベルのパイプラインには、以下のパラメータと構文を含む基本構造があります。詳細については、「*CodePipeline API ガイド*」の「[ActionDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_ActionDeclaration.html)」オブジェクトを参照してください。
次の例は、アクションレベルのパイプライン構造を JSON と YAML の両方で示しています。
------
#### [ YAML ]
```
. . .
stages:
- name: Source
actions:
- name: Source
actionTypeId:
category: Source
owner: AWS
provider: S3
version: '1'
runOrder: 1
configuration:
PollForSourceChanges: 'false'
S3Bucket: amzn-s3-demo-bucket
S3ObjectKey: codedeploy_linux.zip
outputArtifacts:
- name: SourceArtifact
inputArtifacts: []
region: us-west-2
namespace: SourceVariables
- name: Build
actions:
- name: Build
actionTypeId:
category: Build
owner: AWS
provider: CodeBuild
version: '1'
runOrder: 1
configuration:
EnvironmentVariables: >-
[{"name":"ETag","value":"#{SourceVariables.ETag}","type":"PLAINTEXT"}]
ProjectName: my-project
outputArtifacts:
- name: BuildArtifact
inputArtifacts:
- name: SourceArtifact
region: us-west-2
namespace: BuildVariables
runOrder: 1
configuration:
CustomData: >-
Here are the exported variables from the build action: S3 ETAG:
#{BuildVariables.ETag}
outputArtifacts: []
inputArtifacts: []
region: us-west-2
```
------
#### [ JSON ]
```
. . .
"stages": [
{
"name": "Source",
"actions": [
{
"name": "Source",
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"provider": "S3",
"version": "1"
},
"runOrder": 1,
"configuration": {
"PollForSourceChanges": "false",
"S3Bucket": "amzn-s3-demo-bucket",
"S3ObjectKey": "aws-codepipeline-s3-aws-codedeploy_linux.zip"
},
"outputArtifacts": [
{
"name": "SourceArtifact"
}
],
"inputArtifacts": [],
"region": "us-west-2",
"namespace": "SourceVariables"
}
]
},
{
"name": "Build",
"actions": [
{
"name": "Build",
"actionTypeId": {
"category": "Build",
"owner": "AWS",
"provider": "CodeBuild",
"version": "1"
},
"runOrder": 1,
"configuration": {
"EnvironmentVariables": "[{\"name\":\"ETag\",\"value\":\"#{SourceVariables.ETag}\",\"type\":\"PLAINTEXT\"}]",
"ProjectName": "my-build-project"
},
"outputArtifacts": [
{
"name": "BuildArtifact"
}
],
"inputArtifacts": [
{
"name": "SourceArtifact"
}
],
"region": "us-west-2",
"namespace": "BuildVariables"
}
]
. . .
```
------
このプロバイダータイプに該当する `configuration` の例の詳細一覧については、「[プロバイダータイプ別の有効な設定パラメータ](structure-configuration-examples.md)」を参照してください。
アクション構造には、次の要件があります。
+ ステージ内のすべてのアクション名は一意である必要がある
+ 各パイプラインにはソースアクションが必要です。
+ 接続を使用しないソースアクションでは、変更検出をオンに設定することも、オフに設定することもできます。「[変更検出方法](change-detection-methods.md)」を参照してください。
+ これは、同じステージか、それ以降のステージかにかかわらず、すべてのアクションで当てはまりますが、入力アーティファクトは、出力アーティファクトを提供したアクションからの厳密なシーケンスにおける次のアクションである必要はありません。アクションは並行して、異なる出力アーティファクトバンドルを宣言することがあります。これらは、以下のアクションによって順番に消費されます。
+ デプロイ場所として Amazon S3 バケットを使用するときは、オブジェクトキーも指定します。オブジェクトキーはファイル名 (オブジェクト) にするか、プレフィックス (フォルダパス) とファイル名の組み合わせにすることができます。変数を使用して、パイプラインで使用する場所の名前を指定できます。Amazon S3 のデプロイアクションでは、Amazon S3 オブジェクトキーでの以下の変数の使用がサポートされます。
**Amazon S3 での変数の使用**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/action-requirements.html)
## `name`
アクションの名前。
## `region`
プロバイダーが であるアクションの場合 AWS のサービス、リソース AWS リージョン の 。
クロスリージョンアクションの場合は、[`Region`] フィールドを使用してアクションを作成する AWS リージョン を指定します。このアクション用に作成された AWS リソースは、 `region`フィールドで指定されたのと同じリージョンで作成する必要があります。以下のアクションタイプのクロスリージョンアクションは作成できません。
+ ソースアクション
+ サードパーティープロバイダーによるアクション
+ カスタムプロバイダーによるアクション
## `roleArn`
宣言されたアクションを実行する IAM サービスロールの ARN。このアクションを引き受けるには、パイプラインレベルで指定した roleArn を使用します。
## `namespace`
アクションは変数で設定できます。`namespace` フィールドを使用して、実行変数の名前空間と変数の情報を設定します。実行変数とアクション出力変数のリファレンス情報については、「[変数リファレンス](reference-variables.md)」を参照してください。
**注記**
Amazon ECR、Amazon S3、または CodeCommit ソースの場合、入力変換エントリを使用してソースオーバーライドを作成し、パイプラインイベントの EventBridge で `revisionValue` を使用することもできます。ここで、`revisionValue` はオブジェクトキー、コミット、またはイメージ ID のソースイベント変数から派生します。詳細については、[Amazon ECR ソースアクションと EventBridge リソース](create-cwe-ecr-source.md)、[イベントに対して有効にしたソースを使用して Amazon S3 ソースアクションに接続する](create-S3-source-events.md)、または [CodeCommit ソースアクションと EventBridge](triggering.md) の手順に含まれる入力変換エントリのオプション手順を参照してください。
## `actionTypeId`
アクションタイプ ID は、以下の 4 つのフィールドを組み合わせて識別します。
### `category`
ソースアクションなど、パイプライン内のアクションまたはステップのタイプ。アクションタイプ別に有効なプロバイダーのセットがあります。アクションタイプ別の有効なプロバイダーのリストについては、「[アクション構造リファレンス](action-reference.md)」を参照してください。
CodePipeline の有効な `actionTypeId` カテゴリ (アクションタイプ) は、以下のとおりです。
+ `Source`
+ `Build`
+ `Approval`
+ `Deploy`
+ `Test`
+ `Invoke`
+ `Compute`
### `owner`
現在サポートされているすべてのアクションタイプで、有効な所有者の文字列は、`AWS`、`ThirdParty`、または `Custom` のみです。アクション別の有効な所有者の文字列については、「[アクション構造リファレンス](action-reference.md)」を参照してください。
詳細については、[CodePipeline API リファレンス](https://docs.aws.amazon.com/codepipeline/latest/APIReference)を参照してください。
### `version`
アクションのバージョン。
### `provider`
アクションプロバイダー (CodeDeploy など)。
+ アクションカテゴリの有効なプロバイダータイプは、カテゴリによって異なります。例えば、ソースアクションカテゴリの場合、有効なプロバイダータイプは `S3`、`CodeStarSourceConnection`、`CodeCommit`、または `Amazon ECR` です。この例は、`S3` プロバイダーのソースアクションの構造を示しています。
```
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"version": "1",
"provider": "S3"},
```
## `InputArtifacts`
このフィールドには、入力アーティファクト構造が含まれます (アクションカテゴリでサポートされている場合)。アクションの入力アーティファクトは、前述のアクションで宣言された出力アーティファクトと完全に一致する必要がある 例えば、前述のアクションに次の宣言が含まれているとします。
```
"outputArtifacts": [
{
"MyApp"
}
],
```
それ以外に出力アーティファクトが存在しない場合、次のアクションの入力アーティファクトは以下のようになります。
```
"inputArtifacts": [
{
"MyApp"
}
],
```
例えば、ソースアクションはパイプラインの最初のアクションであるため、入力アーティファクトを持つことはできません。ただし、ソースアクションには、後続のアクションによって処理される出力アーティファクトが常に含まれます。ソースアクションの出力アーティファクトは、ソースリポジトリからのアプリケーションファイルで、アーティファクトバケットを介して圧縮して提供されます。これらは、ビルドコマンドを使用してアプリケーションファイルに対して実行する CodeBuild アクションなど、後続のアクションによって処理されます。
出力アーティファクトを持つことができないアクションの例として、デプロイアクションがあります。通常、デプロイアクションは最後のアクションであるため、出力アーティファクトを持ちません。
### `name`
アクションの入力アーティファクトのアーティファクト名。
## `outputArtifacts`
出力アーティファクト名は、パイプライン内で一意である必要があります。例えば、パイプラインには出力アーティファクト `"MyApp"` を含むアクションと、出力アーティファクト `"MyBuiltApp"` を含む別のアクションが含まれる場合があります。ただし、いずれも出力アーティファクト `"MyApp"` を持つ 2 つのアクションを、パイプラインに含めることはできません。
このフィールドには、入力アーティファクト構造が含まれます (アクションカテゴリでサポートされている場合)。アクションの入力アーティファクトは、前のアクションで宣言した出力アーティファクトと完全に一致する必要があります。例えば、前述のアクションに次の宣言が含まれているとします。
```
"outputArtifacts": [
{
"MyApp"
}
],
```
それ以外に出力アーティファクトが存在しない場合、次のアクションの入力アーティファクトは以下のようになります。
```
"inputArtifacts": [
{
"MyApp"
}
],
```
例えば、ソースアクションはパイプラインの最初のアクションであるため、入力アーティファクトを持つことはできません。ただし、ソースアクションには、後続のアクションによって処理される出力アーティファクトが常に含まれます。ソースアクションの出力アーティファクトは、ソースリポジトリからのアプリケーションファイルで、アーティファクトバケットを介して圧縮して提供されます。これらは、ビルドコマンドを使用してアプリケーションファイルに対して実行する CodeBuild アクションなど、後続のアクションによって処理されます。
出力アーティファクトを持つことができないアクションの例として、デプロイアクションがあります。通常、デプロイアクションは最後のアクションであるため、出力アーティファクトを持ちません。
### `name`
アクションの出力アーティファクトのアーティファクト名。
## `configuration` (アクションプロバイダー別）
アクション設定には、プロバイダータイプに適した詳細とパラメータが含まれています。以下のセクションで示すアクション設定パラメータの例は S3 ソースアクションに固有のものです。
アクション設定と入力/出力アーティファクトの制限は、アクションプロバイダー別に異なる場合があります。アクションプロバイダー別のアクション設定の例のリストについては、「[アクション構造リファレンス](action-reference.md)」と、「[プロバイダータイプ別の有効な設定パラメータ](structure-configuration-examples.md)」の表を参照してください。この表には、各アクションの設定パラメータの詳細を示す、プロバイダータイプ別のアクションリファレンスへのリンクがあります。アクションプロバイダー別の入力/出力アーティファクトの制限を示す表については、「[アクションタイプ別の有効な入力/出力アーティファクトの数](reference-action-artifacts.md)」を参照してください。
アクションの使用には、以下の考慮事項が適用されます。
+ ソースアクションには入力アーティファクトがなく、デプロイアクションには出力アーティファクトがありません。
+ 接続を使用しないソースアクションプロバイダー (S3 など) の場合は、変更の検出時にパイプラインを自動的に開始するかどうかを `PollForSourceChanges` パラメータで指定する必要があります。「[`PollForSourceChanges` パラメータの有効な設定](PollForSourceChanges-defaults.md)」を参照してください。
+ 自動変更検出を設定してパイプラインを開始するか、変更検出を無効にするには、「[ソースアクションと変更検出方法](change-detection-methods.md)」を参照してください。
+ フィルタリングを使用してトリガーを設定するには、接続のソースアクションを使用し、「[トリガーとフィルタリングを使用してパイプラインを自動的に開始する](pipelines-triggers.md)」を参照してください。
+ アクション別の出力変数については、「[変数リファレンス](reference-variables.md)」を参照してください。
**注記**
Amazon ECR、Amazon S3、または CodeCommit ソースの場合、入力変換エントリを使用してソースオーバーライドを作成し、パイプラインイベントの EventBridge で `revisionValue` を使用することもできます。ここで、`revisionValue` はオブジェクトキー、コミット、またはイメージ ID のソースイベント変数から派生します。詳細については、[Amazon ECR ソースアクションと EventBridge リソース](create-cwe-ecr-source.md)、[イベントに対して有効にしたソースを使用して Amazon S3 ソースアクションに接続する](create-S3-source-events.md)、または [CodeCommit ソースアクションと EventBridge](triggering.md) の手順に含まれる入力変換エントリのオプション手順を参照してください。
**重要**
30 日以上非アクティブなパイプラインでは、パイプラインのポーリングが無効になります。詳細については、パイプイライン構造リファレンスの「[pollingDisabledAt](pipeline-requirements.md#metadata.pollingDisabledAt)」を参照してください。パイプラインをポーリングからイベントベースの変更検出に移行する手順については、「[変更検出方法](change-detection-methods.md)」を参照してください。
**注記**
CodeCommit および S3 ソースアクションには、設定済みの変更検出リソース (EventBridge ルール)、またはオプションを使用してソースの変更をリポジトリにポーリングする必要があります。Bitbucket、GitHub、または GitHub Enterprise Server のソースアクションを持つパイプラインの場合、ウェブフックを設定したり、デフォルトでポーリングを行う必要はありません。接続アクションは、変更検出を管理します。
## `runOrder`
ステージ内のアクションの実行順序を示す正の整数。ステージ内の並列アクションは、同じ整数を持つアクションとして表示されます。例えば、実行順序が 2 の 2 つのアクションは、ステージ内の最初のアクションの実行後に並列して実行されます。
アクションの `runOrder` のデフォルト値は 1 です。値は、正の整数 (自然数) にする必要があります。分数、10 進数、負の数値、ゼロを使用することはできません。アクションのシリアルシーケンスを指定するには、最初のアクションに最小値を使用し、シーケンスの残りの各アクションにそれより大きい数値を使用します。並列アクションを指定するには、並列に実行する各アクションに同一の整数を使用します。コンソールで、実行するステージのレベルで [**アクショングループを追加する**] を選択して、アクションのシリアルシーケンスを指定できます。[**アクションを追加する**] を選択して、並列シーケンスを指定することもできます。[*アクショングループ*] は、同じレベルにある 1 つ以上のアクションの実行順序を指します。
例えば、3 つのアクションをステージのシーケンスで実行する場合、最初のアクションの `runOrder` 値には 1 を、2 番目のアクションの `runOrder` 値には 2 を、3 番目のアクションの `runOrder` 値には 3 を指定します。ただし、2 番目と 3 番目のアクションを並列に実行する場合、最初のアクションの `runOrder` 値には 1 を、2 番目と 3 番目のアクションの `runOrder` 値にはいずれも 2 を指定します。
**注記**
シリアルアクションの番号付けは、厳密なシーケンスである必要はありません。例えば、シーケンスに 3 つのアクションがあり、2 番目のアクションを削除する場合、3 番目のアクションの `runOrder` 値の番号付けをやり直す必要はありません。アクション (3) の `runOrder` の値は、最初のアクション (1) の `runOrder` の値より大きいため、ステージの最初のアクションが実行されてから順番に実行されます。
# CodePipeline の有効なアクションプロバイダー
パイプライン構造の形式は、パイプラインのアクションとステージをビルドするために使用します。アクションタイプは、アクションカテゴリとアクションプロバイダータイプの組み合わせで構成されます。
アクションカテゴリ別に有効なアクションプロバイダーのリストがあります。アクションカテゴリ別の有効なアクションプロバイダーについては、「[アクション構造リファレンス](action-reference.md)」を参照してください。
アクションカテゴリごとにプロバイダーのセットが指定されています。Amazon S3 など、各アクションプロバイダーには、パイプライン構造のアクションカテゴリの `Provider` フィールドで使用する必要があるプロバイダー名 (`S3` など) があります。
パイプライン構造のアクションカテゴリセクションの `Owner` フィールドには、`AWS`、`ThirdParty`、`Custom` の 3 つの有効な値があります。
アクションプロバイダーのプロバイダー名と所有者情報については、「[アクション構造リファレンス](action-reference.md)」または「[アクションタイプ別の有効な入力/出力アーティファクトの数](reference-action-artifacts.md)」を参照してください。
次の表は、アクションタイプ別の有効なプロバイダーのリストです。
**注記**
Bitbucket、GitHub、または GitHub Enterprise Server アクションについては、[CodeStarSourceConnection (Bitbucket Cloud、GitHub、GitHub Enterprise Server、GitLab.com、および GitLab セルフマネージドアクションの場合)](action-reference-CodestarConnectionSource.md) アクションのリファレンストピックを参照してください。
**アクションタイプ別の有効なアクションプロバイダー**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/actions-valid-providers.html)
CodePipeline の一部のアクションタイプは、一部の AWS リージョンでのみ使用できます。アクションタイプは AWS リージョンで使用できますが、そのアクションタイプの AWS プロバイダーは利用できません。
各アクションプロバイダーの詳細については、「[CodePipeline アクションタイプとの統合](integrations-action-type.md)」を参照してください。
# `PollForSourceChanges` パラメータの有効な設定
`PollForSourceChanges` パラメータのデフォルト設定は、以下の表に示すように、パイプラインの作成に使用した方法によって決まります。多くの場合、`PollForSourceChanges` パラメータはデフォルトで true になるため、無効にする必要があります。
`PollForSourceChanges` パラメータがデフォルトで true になる場合は、以下の操作を行う必要があります。
+ `PollForSourceChanges` パラメータを JSON ファイルまたは CloudFormation テンプレートに追加します。
+ 変更検出リソース (必要に応じて CloudWatch Events ルール) を作成します。
+ `PollForSourceChanges` パラメータを false に設定します。
**注記**
CloudWatch Events ルールまたはウェブフックを作成する場合は、このパラメータを false に設定してパイプラインが複数回トリガーされるのを避ける必要があります。
`PollForSourceChanges` パラメータは、Amazon ECR ソースアクションには使用されません。
+
**`PollForSourceChanges` パラメータのデフォルト**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/PollForSourceChanges-defaults.html)
# アクションタイプ別の有効な入力/出力アーティファクトの数
アクションタイプおよびプロバイダーに応じて、入力/出力アーティファクトを以下の数にすることができます。
**アーティファクトのアクションタイプの制約**
| 所有者 | アクションのタイプ | プロバイダー | 入力アーティファクト有効な数 | 出力アーティファクトの有効な数 |
| --- | --- | --- | --- | --- |
| AWS | ソース | S3 | 0 | 1 |
| AWS | ソース | CodeCommit | 0 | 1 |
| AWS | ソース | ECR | 0 | 1 |
| ThirdParty | ソース | CodeStarSourceConnection | 0 | 1 |
| AWS | 構築 | CodeBuild | 1～5 | 0～5 |
| AWS | テスト | CodeBuild | 1～5 | 0～5 |
| AWS | テスト | DeviceFarm | 1 | 0 |
| AWS | 承認 | ThirdParty | 0 | 0 |
| AWS | デプロイ | S3 | 1 | 0 |
| AWS | デプロイ | CloudFormation | 0～10 | 0～1 |
| AWS | デプロイ | CodeDeploy | 1 | 0 |
| AWS | デプロイ | ElasticBeanstalk | 1 | 0 |
| AWS | デプロイ | OpsWorks | 1 | 0 |
| AWS | デプロイ | ECS | 1 | 0 |
| AWS | デプロイ | ServiceCatalog | 1 | 0 |
| AWS | Invoke | Lambda | 0～5 | 0～5 |
| ThirdParty | デプロイ | AlexaSkillsKit | 1～2 | 0 |
| Custom | 構築 | Jenkins | 0〜5 | 0～5 |
| Custom | テスト | Jenkins | 0〜5 | 0～5 |
| Custom | サポートされているすべてのカテゴリ | カスタムアクションで指定 | 0〜5 | 0～5 |
# プロバイダータイプ別の有効な設定パラメータ
このセクションでは、アクションプロバイダー別の有効な `configuration` パラメータを示します。
各アクションには有効なアクション設定が必要です。この設定は、アクションのプロバイダータイプによって異なります。次の表は、有効な各プロバイダータイプで必要なアクション設定要素を示しています。
**プロバイダータイプのアクション設定プロパティ**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/structure-configuration-examples.html)
次の例は、Alexa Skills Kit を使用するデプロイアクションの有効な設定を示しています。
```
"configuration": {
"ClientId": "amzn1.application-oa2-client.aadEXAMPLE",
"ClientSecret": "****",
"RefreshToken": "****",
"SkillId": "amzn1.ask.skill.22649d8f-0451-4b4b-9ed9-bfb6cEXAMPLE"
}
```
次の例は、手動承認の有効な設定を示しています。
```
"configuration": {
"CustomData": "Comments on the manual approval",
"ExternalEntityLink": "http://my-url.com",
"NotificationArn": "arn:aws:sns:us-west-2:12345EXAMPLE:Notification"
}
```