CodePipeline パイプライン構造リファレンス - AWS CodePipeline

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

CodePipeline パイプライン構造リファレンス

デフォルトでは、AWS CodePipeline に正常に作成されたパイプラインには、有効な構造が含まれます。ただし、JSON ファイルを手動で作成または編集して、AWS CLI からパイプラインを作成または更新する場合、意図せずに無効な構造が作成される場合があります。次のリファレンスは、パイプライン構造の要件や、問題のトラブルシューティング方法を理解するのに役立ちます。すべてのパイプラインに適用される AWS の CodePipeline 中のクォータ の制約を参照してください。

CodePipeline での有効なアクションタイプとアクションプロバイダー

パイプライン構造の形式は、パイプラインのアクションとステージをビルドするために使用します。アクションタイプは、アクションカテゴリとアクションプロバイダータイプの組み合わせで構成されます。

CodePipeline の有効なアクションカテゴリは以下のとおりです。

  • ソース

  • ビルド

  • テスト

  • デプロイ

  • 承認

  • 呼び出し

アクションカテゴリごとにプロバイダーのセットが指定されています。Amazon S3 など、各アクションプロバイダーには、パイプライン構造のアクションカテゴリの Provider フィールドで使用する必要があるプロバイダー名 (S3 など) があります。

パイプライン構造のアクションカテゴリセクションの Owner フィールドには、AWSThirdPartyCustom の 3 つの有効な値があります。

アクションプロバイダーのプロバイダー名と所有者情報を検索する方法については、「アクション構造リファレンス」または「各アクションタイプの入出力アーティファクトの数」を参照してください。

次の表は、アクションタイプ別の有効なプロバイダーのリストです。

注記

Bitbucket、GitHub、または GitHub Enterprise Server アクションについては、CodeStarSourceConnection Bitbucket の場合、 GitHub、および GitHub Enter アクションのリファレンストピックを参照してください。

アクションタイプ別の有効なアクションプロバイダー
アクションカテゴリ 有効なアクションプロバイダー アクションリファレンス
ソース Amazon S3 Amazon S3 ソースアクション
Amazon ECR Amazon ECR
CodeCommit CodeCommit
CodeStarSourceConnection (Bitbucket、GitHub、GitHub Enterprise Server アクションの場合) CodeStarSourceConnection Bitbucket の場合、 GitHub、および GitHub Enter
ビルド CodeBuild AWS CodeBuild
カスタム CloudBees 各アクションタイプの入出力アーティファクトの数
カスタム Jenkins 各アクションタイプの入出力アーティファクトの数
カスタム TeamCity 各アクションタイプの入出力アーティファクトの数
テスト CodeBuild AWS CodeBuild
AWS Device Farm 各アクションタイプの入出力アーティファクトの数
カスタム BlazeMeter 各アクションタイプの入出力アーティファクトの数
サードパーティー GhostInspector 各アクションタイプの入出力アーティファクトの数
カスタム Jenkins 各アクションタイプの入出力アーティファクトの数
サードパーティー Micro Focus StormRunner Load 各アクションタイプの入出力アーティファクトの数
サードパーティー Nouvola 各アクションタイプの入出力アーティファクトの数
サードパーティー Runscope 各アクションタイプの入出力アーティファクトの数
デプロイ Amazon S3 Amazon S3 デプロイアクション
AWS CloudFormation AWS CloudFormation
CodeDeploy 各アクションタイプの入出力アーティファクトの数
Amazon ECS 各アクションタイプの入出力アーティファクトの数
Amazon ECS (Blue/Green) (これは CodeDeployToECS アクションです) 各アクションタイプの入出力アーティファクトの数
Elastic Beanstalk 各アクションタイプの入出力アーティファクトの数
AWS AppConfig AWS AppConfig
AWS OpsWorks 各アクションタイプの入出力アーティファクトの数
AWS Service Catalog 各アクションタイプの入出力アーティファクトの数
Amazon Alexa 各アクションタイプの入出力アーティファクトの数
カスタム XebiaLabs 各アクションタイプの入出力アーティファクトの数
承認 手動 各アクションタイプの入出力アーティファクトの数
呼び出し AWS Lambda AWS Lambda
AWS Step Functions AWS Step Functions

CodePipeline の一部のアクションタイプは、限定された AWS リージョンでのみ使用できます。AWS リージョンでアクションタイプが使用できても、そのアクションタイプの AWS プロバイダーが使用できない場合があります。

各アクションプロバイダーの詳細については、「との統合 CodePipeline アクションタイプ」を参照してください。

以下のセクションでは、アクションタイプ別のプロバイダー情報と設定プロパティの例を示します。

CodePipeline でのパイプラインおよびステージ構造の要件

2 ステージパイプラインの基本構造は次のとおりです。

{ "roleArn": "An IAM ARN for a service role, such as arn:aws:iam::80398EXAMPLE:role/CodePipeline_Service_Role", "stages": [ { "name": "SourceStageName", "actions": [ ... See CodePipeline でのアクション構造の要件 ... ] }, { "name": "NextStageName", "actions": [ ... See CodePipeline でのアクション構造の要件 ... ] } ], "artifactStore": { "type": "S3", "location": "The name of the Amazon S3 bucket automatically generated for you the first time you create a pipeline using the console, such as codepipeline-us-east-2-1234567890, or any Amazon S3 bucket you provision for this purpose" }, "name": "YourPipelineName", "version": 1 }

パイプライン構造には、次の要件があります。

  • パイプラインには、少なくとも 2 つのステージが含まれている必要がある

  • パイプラインの最初のステージには、少なくとも 1 つのソースアクションが含まれている必要がある ソースアクションのみを含めることができる

  • ソースアクションを含むことができるのは、パイプラインの最初のステージのみである

  • 各パイプラインの少なくとも 1 つのステージに、ソースアクション以外のアクションが含まれている必要がある

  • パイプライン内のすべてのステージ名は一意である必要がある

  • ステージ名は、CodePipeline コンソール内で編集することはできません。AWS CLI を使用してステージ名を編集し、そのステージに 1 つ以上のシークレットパラメータ (OAuth トークンなど) を持つアクションが含まれる場合、そのシークレットパラメータの値は保持されません。パラメータ値 (AWS CLI よって返される JSON で、4 つのアスタリスクでマスクされている) は手動で入力し、JSON 構造に含める必要があります。

  • この artifactStore フィールドには、同じ AWS リージョン内のすべてのアクションを持つパイプラインのアーティファクトバケットタイプと場所が含まれます。パイプラインとは異なるリージョンにアクションを追加すると、artifactStores マッピングを使用して、アクションが実行される各 AWS リージョンのアーティファクトバケットが一覧表示されます。パイプラインを作成または編集する場合は、パイプラインリージョンにアーティファクトバケットが必要であり、アクションを実行する予定のリージョンごとに 1 つのアーティファクトバケットが必要です。

    以下の例では、artifactStores パラメータを使用するクロスリージョンアクションを含むパイプラインの基本構造を示しています。

    "pipeline": { "name": "YourPipelineName", "roleArn": "CodePipeline_Service_Role", "artifactStores": { "us-east-1": { "type": "S3", "location": "S3 artifact bucket name, such as codepipeline-us-east-1-1234567890" }, "us-west-2": { "type": "S3", "location": "S3 artifact bucket name, such as codepipeline-us-west-2-1234567890" } }, "stages": [ { ...
  • パイプラインメタデータフィールドはパイプライン構造とは異なり、編集することはできません。パイプラインを更新すると、updated メタデータフィールドの日付が自動的に変更されます。

  • パイプラインを編集または更新する場合、パイプライン名は変更できません。

    注記

    既存のパイプラインの名前を変更するには、CLI get-pipeline コマンドを使用して、パイプライン構造を含む JSON ファイルを作成します。次に、CLI create-pipeline コマンドを使用してその構造を持つ新しいパイプラインを作成し、新しい名前を付けます。

パイプラインのバージョン番号は自動的に生成され、パイプラインを更新するたびに更新されます。

CodePipeline でのアクション構造の要件

アクション構造の概要は次のとおりです。

[ { "inputArtifacts": [ An input artifact structure, if supported for the action category ], "name": "ActionName", "region": "Region", "namespace": "source_namespace", "actionTypeId": { "category": "An action category", "owner": "AWS", "version": "1" "provider": "A provider type for the action category", }, "outputArtifacts": [ An output artifact structure, if supported for the action category ], "configuration": { Configuration details appropriate to the provider type }, "runOrder": A positive integer that indicates the run order within the stage, } ]

このプロバイダータイプに該当する configuration の例の詳細一覧については、「プロバイダータイプ別の設定の詳細」を参照してください。

アクション構造には、次の要件があります。

  • ステージ内のすべてのアクション名は一意である必要がある

  • アクションの入力アーティファクトは、前述のアクションで宣言された出力アーティファクトと完全に一致する必要がある 例えば、前述のアクションに次の宣言が含まれているとします。

    "outputArtifacts": [ { "MyApp" } ],

    それ以外に出力アーティファクトが存在しない場合、次のアクションの入力アーティファクトは以下のようになります。

    "inputArtifacts": [ { "MyApp" } ],

    これは、同じステージか、それ以降のステージかにかかわらず、すべてのアクションで当てはまりますが、入力アーティファクトは、出力アーティファクトを提供したアクションからの厳密なシーケンスにおける次のアクションである必要はありません。アクションは並行して、異なる出力アーティファクトバンドルを宣言することがあります。これらは、以下のアクションによって順番に消費されます。

  • 出力アーティファクト名は、パイプライン内で一意である必要があります。例えば、パイプラインには出力アーティファクト "MyApp" を含むアクションと、出力アーティファクト "MyBuiltApp" を含む別のアクションが含まれる場合があります。ただし、いずれも出力アーティファクト "MyApp" を持つ 2 つのアクションを、パイプラインに含めることはできません。

  • クロスリージョンアクションでは、Region フィールドを使用して、アクションが作成される AWS リージョンを指定します。このアクション用に作成された AWS リソースは、region フィールドで指定されているリージョンと同じリージョンに作成する必要があります。以下のアクションタイプのクロスリージョンアクションは作成できません。

    • ソースアクション

    • サードパーティープロバイダーによるアクション

    • カスタムプロバイダーによるアクション

  • アクションは変数で設定できます。namespace フィールドを使用して、実行変数の名前空間と変数の情報を設定します。実行変数とアクション出力変数のリファレンス情報については、「変数」を参照してください。

  • 現在サポートされているすべてのアクションタイプで、有効な所有者の文字列は、AWSThirdParty、または Custom のみです。詳細については、CodePipeline API リファレンスを参照してください。

  • アクションの 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 の値より大きいため、ステージの最初のアクションが実行されてから順番に実行されます。

  • デプロイ場所として Amazon S3 バケットを使用するときは、オブジェクトキーも指定します。オブジェクトキーはファイル名 (オブジェクト) にするか、プレフィックス (フォルダパス) とファイル名の組み合わせにすることができます。変数を使用して、パイプラインで使用する場所の名前を指定できます。Amazon S3 のデプロイアクションでは、Amazon S3 オブジェクトキーでの以下の変数の使用がサポートされます。

    Amazon S3 での変数の使用
    変数 コンソール入力の例 出力
    datetime js-application/{datetime}.zip この形式の UTC タイムスタンプ: <YYYY>-<MM>-DD>_<HH>-<MM>-<SS>

    例:

    js-application/2019-01-10_07-39-57.zip

    uuid js-application/{uuid}.zip UUID は、他のすべての識別子と異なることが保証されるグローバル一意識別子です。この形式の UUID (すべての桁は 16 進形式): <8 桁>-<4 桁>-4 桁>-<4 桁>-<12 桁>

    例:

    js-application/54a60075-b96a-4bf3-9013-db3a9EXAMPLE.zip

  • 以下に示すのは、CodePipeline の有効な actionTypeId カテゴリです。

    • Source

    • Build

    • Approval

    • Deploy

    • Test

    • Invoke

    一部のプロバイダータイプと設定オプションを以下に示します。

  • アクションカテゴリの有効なプロバイダータイプは、カテゴリによって異なります。例えば、ソースアクションタイプの場合、有効なプロバイダータイプは S3GitHubCodeCommit、または Amazon ECR です。この例は、S3 プロバイダーのソースアクションの構造を示しています。

    "actionTypeId": { "category": "Source", "owner": "AWS", "version": "1", "provider": "S3"},
  • 各アクションには有効なアクション設定が必要です。この設定は、アクションのプロバイダータイプによって異なります。次の表は、有効な各プロバイダータイプで必要なアクション設定要素を示しています。

    プロバイダータイプのアクション設定プロパティ
    プロバイダー名 アクションタイプでのプロバイダー名 設定プロパティ 必須プロパティかどうか
    Amazon S3 (デプロイアクションプロバイダー) Amazon S3 デプロイアクションパラメータに関連する例などの詳細については、「Amazon S3 デプロイアクション」を参照してください。
    Amazon S3 (ソースアクションプロバイダー) Amazon S3 ソースアクションパラメータに関連する例などの詳細については、「Amazon S3 ソースアクション」を参照してください。
    Amazon ECR Amazon ECR パラメータに関連する例などの詳細については、「Amazon ECR」を参照してください。
    CodeCommit CodeCommit パラメータに関連する例などの詳細については、「CodeCommit」を参照してください。
    GitHub GitHub パラメータに関連する例などの詳細については、「GitHub バージョン 1 ソースアクション構造のリファレンス」を参照してください。
    AWS CloudFormation AWS CloudFormation パラメータに関連する例などの詳細については、「AWS CloudFormation」を参照してください。
    CodeBuild CodeBuild パラメータに関連する詳細な説明と例については、「AWS CodeBuild」を参照してください。
    CodeDeploy CodeDeploy パラメータに関連する詳細な説明と例については、「AWS CodeDeploy」を参照してください。
    AWS Device Farm AWS Device Farm パラメータに関連する詳細な説明と例については、「AWS Device Farm」を参照してください。
    AWS Elastic Beanstalk ElasticBeanstalk ApplicationName 必須
    EnvironmentName 必須
    AWS Lambda AWS Lambda パラメータに関連する例などの詳細については、「AWS Lambda」を参照してください。
    AWS OpsWorks Stacks OpsWorks Stack 必須
    Layer 任意
    App 必須
    Amazon ECS Amazon ECS パラメータに関連する詳細な説明と例については、「Amazon Elastic Container Service」を参照してください。
    Amazon ECS と CodeDeploy (Blue/Green) Amazon ECS および CodeDeploy blue/green パラメータに関連する詳細な説明と例については、「Amazon Elastic Service と CodeDeploy Blue-Green」を参照してください。
    AWS Service Catalog ServiceCatalog TemplateFilePath 必須
    ProductVersionName 必須
    ProductType 必須
    ProductVersionDescription 任意
    ProductId 必須
    Alexa Skills Kit AlexaSkillsKit ClientId 必須
    ClientSecret 必須
    RefreshToken 必須
    SkillId 必須
    Jenkins CodePipeline Plugin for Jenkins で指定したアクションの名前 (MyJenkinsProviderName など) ProjectName 必須
    手動承認 Manual CustomData 任意
    ExternalEntityLink 任意
    NotificationArn 任意

各アクションタイプの入出力アーティファクトの数

アクションタイプによっては、入出力アーティファクトの数は以下にすることができます。

アーティファクトのアクションタイプの制約
所有者 アクションのタイプ プロバイダー 入力アーティファクト有効な数 出力アーティファクトの有効な数
AWS ソース Amazon S3 0 1
AWS ソース CodeCommit 0 1
AWS ソース Amazon ECR 0 1
ThirdParty ソース GitHub 0 1
AWS ビルド CodeBuild 1~5 0~5
AWS テスト CodeBuild 1~5 0~5
AWS テスト AWS Device Farm 1 0
AWS 承認 手動 0 0
AWS デプロイ Amazon S3 1 0
AWS デプロイ AWS CloudFormation 0~10 0~1
AWS デプロイ CodeDeploy 1 0
AWS デプロイ AWS Elastic Beanstalk 1 0
AWS デプロイ AWS OpsWorks Stacks 1 0
AWS デプロイ Amazon ECS 1 0
AWS デプロイ AWS Service Catalog 1 0
AWS 呼び出し AWS Lambda 0~5 0~5
ThirdParty デプロイ Alexa Skills Kit 1~2 0
Custom ビルド Jenkins 0~5 0~5
Custom テスト Jenkins 0~5 0~5
Custom サポートされているすべてのカテゴリ カスタムアクションで指定 0~5 0~5

PollForSourceChanges パラメータのデフォルト設定

PollForSourceChanges パラメータのデフォルト設定は、以下の表に示すように、パイプラインの作成に使用した方法によって決まります。多くの場合、PollForSourceChanges パラメータはデフォルトで true になるため、無効にする必要があります。

PollForSourceChanges パラメータがデフォルトで true になる場合は、以下の操作を行う必要があります。

  • PollForSourceChanges パラメータを JSON ファイルまたは AWS CloudFormation テンプレートに追加します。

  • 変更検出リソース (必要に応じて CloudWatch Events ルール) を作成します。

  • PollForSourceChanges パラメータを false に設定します。

    注記

    CloudWatch Events ルールまたはウェブフックを作成する場合は、このパラメータを false に設定してパイプラインが複数回トリガーされるのを避ける必要があります。

    PollForSourceChanges パラメータは、Amazon ECR ソースアクションには使用されません。

  • PollForSourceChanges パラメータのデフォルト設定
    ソース 作成方法 JSON 構造の出力の設定例
    CodeCommit パイプラインはコンソールで作成されます (変更検出リソースもコンソールで作成されます)。パラメータは、パイプライン構造の出力に表示され、デフォルトで false になります。
    BranchName": "main", "PollForSourceChanges": "false", "RepositoryName": "my-repo"
    パイプラインは CLI または AWS CloudFormation で作成されます。PollForSourceChanges パラメータは JSON 出力に表示されませんが、true に設定されます²。
    BranchName": "main", "RepositoryName": "my-repo"
    Amazon S3 パイプラインはコンソールで作成されます (変更検出リソースもコンソールで作成されます)。パラメータは、パイプライン構造の出力に表示され、デフォルトで false になります。
    "S3Bucket": "my-bucket", "S3ObjectKey": "object.zip", "PollForSourceChanges": "false"
    パイプラインは CLI または AWS CloudFormation で作成されます。PollForSourceChanges パラメータは JSON 出力に表示されませんが、true に設定されます²。
    "S3Bucket": "my-bucket", "S3ObjectKey": "object.zip"
    GitHub パイプラインはコンソールで作成されます (変更検出リソースもコンソールで作成されます)。パラメータは、パイプライン構造の出力に表示され、デフォルトで false になります。
    "Owner": "MyGitHubAccountName", "Repo": "MyGitHubRepositoryName" "PollForSourceChanges": "false", "Branch": "main" "OAuthToken": "****"
    パイプラインは CLI または AWS CloudFormation で作成されます。PollForSourceChanges パラメータは JSON 出力に表示されませんが、true に設定されます²。
    "Owner": "MyGitHubAccountName", "Repo": "MyGitHubRepositoryName", "Branch": "main", "OAuthToken": "****"

    ² PollForSourceChanges は、特定のポイントで JSON 構造または AWS CloudFormation テンプレートに追加されると、次のように表示されます。

    "PollForSourceChanges": "true",

    ³ 各ソースプロバイダーに適用される変更検出リソースの詳細については、「変更検出方法」を参照してください。

プロバイダータイプ別の設定の詳細

このセクションでは、アクションプロバイダー別の有効な configuration パラメータを示します。

次の例は、個別の設定ファイルを使用しないでパイプラインをコンソールで作成する場合に、AWS Service Catalog を使用するデプロイアクションの有効な設定を示しています。

"configuration": { "TemplateFilePath": "S3_template.json", "ProductVersionName": "devops S3 v2", "ProductType": "CLOUD_FORMATION_TEMPLATE", "ProductVersionDescription": "Product version description", "ProductId": "prod-example123456" }

次の例は、個別の sample_config.json 設定ファイルを使用してパイプラインをコンソールで作成する場合に、AWS Service Catalog を使用するデプロイアクションの有効な設定を示しています。

"configuration": { "ConfigurationFilePath": "sample_config.json", "ProductId": "prod-example123456" }

次の例は、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" }