翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # アクションの宣言 アクションレベルのパイプラインには、以下のパラメータと構文を含む基本構造があります。詳細については、「*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` の値より大きいため、ステージの最初のアクションが実行されてから順番に実行されます。