Amazon CodeCatalyst は新規のお客様には提供されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「[CodeCatalyst から移行する方法](migration.md)」を参照してください。翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ワークフローを使用して構築、テスト、デプロイするアプリケーションコードは、[CodeCatalyst 開発環境](devenvironment.md)で記述し、[CodeCatalyst ソースリポジトリ](source.md)にプッシュしたら、デプロイできます。これを自動的に行うにはワークフローを使用します。 *ワークフロー*は、継続的統合と継続的デリバリー (CI/CD) システムの一部としてコードを構築、テスト、デプロイする方法を記述する自動手順です。ワークフローは、ワークフローの実行中に実行する一連のステップまたは*アクション*を定義します。ワークフローは、ワークフローを開始するイベント、または*トリガー*も定義します。ワークフローを設定するには、CodeCatalyst コンソールの[ビジュアルエディタまたは YAML エディタ](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors)を使用して*ワークフロー定義ファイル*を作成します。 **ヒント** プロジェクトでワークフローを使用する方法を簡単に確認するには、[ブループリントを使用してプロジェクトを作成](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template)します。各ブループリントは、レビュー、実行、実験可能な機能するワークフローをデプロイします。 ## ワークフロー定義ファイルについて *ワークフロー定義ファイル*は、ワークフローを記述する YAML ファイルです。デフォルトでは、ファイルは[ソースリポジトリ](source-repositories.md)のルートにある `~/.codecatalyst/workflows/` フォルダに保存されます。ファイルには .yml または .yaml 拡張子を使用でき、拡張子は小文字にする必要があります。単純なワークフロー定義ファイルの例を次に示します。この例の各行については、次の表で説明します。 ``` Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main Actions: Build: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: docker build -t MyApp:latest . ``` | 線グラフ | 説明 | | --- | --- | |

Name: MyWorkflow

| ワークフローの名前を指定します。`Name` プロパティの詳細については、「[最上位プロパティ](workflow-reference.md#workflow.top.level)」を参照してください。 | |

SchemaVersion: 1.0

| ワークフロースキーマのバージョンを指定します。`SchemaVersion` プロパティの詳細については、「[最上位プロパティ](workflow-reference.md#workflow.top.level)」を参照してください。 | |

RunMode: QUEUED

| CodeCatalystが複数の実行をどのように処理するかを示します。実行モードの詳細については、「[実行のキュー動作の構成](workflows-configure-runs.md)」を参照してください。 | |

Triggers:

| ワークフローの実行を開始するロジックを指定します。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 | |

- Type: PUSH
  Branches:
    - main

| デフォルトのソースリポジトリの `main` ブランチにコードをプッシュするたびにワークフローを開始する必要があることを示します。ワークフローの詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。 | |

Actions:

| ワークフローの実行中に実行するタスクを定義します。この例では、`Actions` セクションは `Build` という 1 つのアクションを定義します。アクションの詳細については、「[ワークフローアクションの構成](workflows-actions.md)」を参照してください。 | |

Build:

| `Build` アクションのプロパティを定義します。ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。 | |

Identifier: aws/build@v1

| ビルドアクションの一意のハードコードされた識別子を指定します。 | |

Inputs:
  Sources:
    - WorkflowSource

| ビルドアクションが処理を完了するために必要なファイルを見つけるには、`WorkflowSource` ソースリポジトリを参照する必要があることを示します。詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。 | |

Configuration:

| ビルドアクションに固有の設定プロパティが含まれます。 | |

Steps:
  - Run: docker build -t MyApp:latest .

| `MyApp` という名前の Docker イメージを構築して `latest` のタグを付けるようビルドアクションに指示します。 | ワークフロー定義ファイルで使用可能なプロパティをすべて集めた完全なリストについては、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 ## CodeCatalyst コンソールのビジュアルエディタと YAML エディタの使用ワークフロー定義ファイルを作成および編集するのに任意のエディタを使用できますが、CodeCatalyst コンソールのビジュアルエディタまたは YAML エディタを使用することをお勧めします。これらのエディタには、YAML プロパティの名、値、ネスティング、スペース、大文字化などが正しいことを確認するのに役立つ便利なファイル検証が用意されています。次の画像は、ビジュアルエディタのワークフローを示します。ビジュアルエディタでは、ワークフロー定義ファイルを作成および設定するための完全なユーザーインターフェイスを利用できます。ビジュアルエディタには、ワークフローの主要コンポーネントを示すワークフロー図 (1) と設定エリア (2) が含まれています。 ![\[ワークフロービジュアルエディタ\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/workflow-visual-editor.png) 別の選択肢として、次の画像に示す YAML エディタを使用することもできます。YAML エディタを使用すると、(チュートリアルなどからの) 大きなコードブロックに貼り付けたり、ビジュアルエディタでは提供されない高度なプロパティを追加したりできます。 ![\[ワークフロー YAML エディタ\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/workflow-yaml-editor.png) ビジュアルエディタから YAML エディタに切り替えると、基盤となる YAML コードに設定が及ぼす影響を確認できます。 ## ワークフローの検出 **[ワークフロー]** 概要ページには、お使いのワークフローを同じプロジェクトで設定した他のワークフローと共に表示できます。次の図は、**[ワークフロー]** 概要ページを示します。**BuildToProd** と **UnitTests** という 2 つのワークフローが入力されています。どちらも数回実行されていることがわかります。**[最近の実行]** を選択して実行履歴をすばやく確認したり、ワークフローの名前を選択してワークフローの YAML コードとその他の詳細情報を確認したりできます。 ![\[ワークフローログ\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/workflow-list.png) ## ワークフロー実行の詳細の表示 **[ワークフロー]** 概要ページで実行を選択すると、ワークフロー実行の詳細を表示できます。次の図は、ソースへのコミット時に自動的に開始された **Run-cc11d** というワークフロー実行の詳細を示しています。ワークフロー図は、アクションが失敗したことを示します (1)。ログ (2) に移動して詳細なログメッセージを表示し、問題をトラブルシューティングできます。ワークフロー実行の詳細については、「[ワークフローの実行](workflows-working-runs.md)」を参照してください。 ![\[ワークフローログ\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/workflow-visual-logs.png) ## 次の手順ワークフローの概念の詳細については、「[ワークフローの概念](workflows-concepts.md)」を参照してください。最初のワークフローを作成するには、「[初めてのワークフロー](workflows-getting-started.md)」を参照してください。 # ワークフローの概念 CodeCatalyst でワークフローを使用してコードを構築、テスト、またはデプロイするときに知っておくべき概念と用語をいくつか紹介します。 ## ワークフロー *ワークフロー*は、CI/CD (Continuous Integration/Continuous Delivery) システムの一部としてコードを構築、テスト、デプロイする方法を説明する自動手順です。ワークフローは、ワークフローの実行中に実行する一連のステップまたは*アクション*を定義します。ワークフローは、ワークフローを開始するイベント、または*トリガー*も定義します。ワークフローを設定するには、CodeCatalyst コンソールの[ビジュアルエディタまたは YAML エディタ](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors)を使用して*ワークフロー定義ファイル*を作成します。 **ヒント** プロジェクトでワークフローを使用する方法を簡単に確認するには、[ブループリントを使用してプロジェクトを作成](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template)します。各ブループリントは、レビュー、実行、実験可能な機能するワークフローをデプロイします。 ## ワークフロー定義ファイル *ワークフロー定義ファイル*は、ワークフローを記述する YAML ファイルです。デフォルトでは、ファイルは[ソースリポジトリ](source-repositories.md)のルートにある `~/.codecatalyst/workflows/` フォルダに保存されます。ファイルには .yml または .yaml 拡張子を使用でき、拡張子は小文字にする必要があります。ワークフロー定義ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 ## アクション *アクション*はワークフローの主要な構成要素であり、ワークフローの実行中に実行する作業またはタスクの論理単位を定義します。通常、ワークフローには、設定方法に応じて順次または並列に実行される複数のアクションが含まれます。アクションの詳細については、「[ワークフローアクションの構成](workflows-actions.md)」を参照してください。 ## アクショングループ *アクショングループ*には 1 つ以上のアクションが含まれています。アクションをアクショングループにグループ化すると、ワークフローを整理するのに役立ち、異なるグループ間の依存関係を構成できるようになります。アクショングループの詳細については、「[アクショングループへのアクションのグループ化](workflows-group-actions.md)」を参照してください。 ## アーティファクト *アーティファクト*はワークフローアクションの出力であり、通常はフォルダまたはファイルのアーカイブで構成されます。アーティファクトは、アクション間でのファイルや情報の共有を可能にするため重要です。アーティファクトの詳細については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 ## コンピューティング *コンピューティング*とは、CodeCatalyst がワークフローアクションを実行するために管理および保守するコンピューティングエンジン (CPU、メモリ、およびオペレーティングシステム) を指します。コンピューティングの詳細については、「[コンピューティングイメージとランタイムイメージの構成](workflows-working-compute.md)」を参照してください。 ## 環境 CodeCatalyst *環境*は、[開発環境](https://docs.aws.amazon.com/codecatalyst/latest/userguide/devenvironment.html)と混同されないように、CodeCatalyst [ワークフロー](workflow.md)が接続するターゲット AWS アカウントとオプションの Amazon VPC を定義します。環境は、ターゲットアカウント内の AWS サービスとリソースにアクセスするためにワークフローが必要とする [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)も定義します。複数の環境をセットアップし、開発、テスト、ステージング、本番稼働などの名前を付けることができます。これらの環境にデプロイすると、デプロイに関する情報が環境内で CodeCatalyst の **[デプロイアクティビティ]** タブと **[デプロイターゲット]** タブに表示されます。環境の詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」を参照してください。 ## ゲート *ゲート*は、特定の条件が満たされない限り、ワークフロー実行が続行されないようにするために使用できるワークフローコンポーネントです。ゲートの例として、ワークフロー実行の続行を許可する前に CodeCatalyst コンソールでユーザーが承認を送信する必要がある**承認**ゲートがあります。ワークフロー内の連続するアクションの間にゲートを追加することも、最初のアクション (**ソース**のダウンロード直後に実行) の前にゲートを追加することもできます。必要に応じて、最後のアクションの後にゲートを追加することもできます。ゲートの詳細については、「[ゲートを使用したワークフロー実行の続行防止](workflows-gates.md)」を参照してください。 ## レポート *レポート*には、ワークフロー実行中に発生するテストの詳細が含まれています。テストレポート、コードカバレッジレポート、ソフトウェア構成分析レポート、静的分析レポートなどのレポートを作成できます。レポートを使用することで、ワークフロー中に問題をトラブルシューティングできます。複数のワークフローからのレポートが多数ある場合は、レポートを使用して傾向と失敗率を表示し、アプリケーションとデプロイの構成を最適化できます。レポートの詳細については、「[品質レポートのタイプ](test-workflow-actions.md#test-reporting)」を参照してください。 ## 実行 *実行*はワークフローの 1 回の反復です。実行中、CodeCatalyst ではワークフロー構成ファイルで定義されているアクションを実行し、関連するログ、アーティファクト、変数を出力します。実行の詳細については、「[ワークフローの実行](workflows-working-runs.md)」を参照してください。 ## [Sources] (出典) *ソース*は*入力ソース*とも呼ばれ、[ワークフローアクション](workflows-actions.md)がオペレーションの実行に必要なファイルを取得するために接続するソースリポジトリです。例えば、ワークフローアクションがソースリポジトリに接続して、アプリケーションを構築するためにアプリケーションソースファイルを取得する場合があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。 ## [変数] *変数*は、Amazon CodeCatalyst ワークフローで参照できる情報を含むキーと値のペアです。変数の値部分は、ワークフロー実行時に実際の値に置き換えられます。変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 ## ワークフロートリガー *ワークフロートリガー* (または単に*トリガー*) を使用すると、コードプッシュなどの特定のイベントが発生したときにワークフロー実行を自動的に開始できます。ソフトウェアデベロッパーが CodeCatalyst コンソールを使用してワークフロー実行を手動で開始する必要がないようにトリガーを構成することもできます。次の 3 種類のトリガーを使用できます。 + **プッシュ** – コードプッシュトリガーにより、コミットがプッシュされるたびにワークフロー実行が開始されます。 + **プルリクエスト** – プルリクエストトリガーにより、プルリクエストが作成、改訂、またはクローズされるたびにワークフロー実行が開始されます。 + **スケジュール** – スケジュールトリガーにより、定義したスケジュールに沿ってワークフロー実行が開始されます。スケジュールトリガーを使用してソフトウェアのビルドを毎晩実行し、ソフトウェアデベロッパーが翌日の朝に最新ビルドで作業できるようにすることを検討してください。プッシュ、プルリクエスト、スケジュールの各トリガーは単独で使用することも、同じワークフロー内で組み合わせて使用することもできます。トリガーは必須ではありません。トリガーを構成しない場合はワークフローを手動で開始する必要があります。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 # 初めてのワークフローこのチュートリアルでは、最初のワークフローを作成および構成する方法について説明します。 **ヒント** 事前構成済みワークフローから開始する場合は、「[ブループリントを使用したプロジェクトの作成](projects-create.md#projects-create-console-template)」を参照してください。機能するワークフロー、サンプルアプリケーション、およびその他のリソースを使用してプロジェクトを設定する手順が記載されています。 **Topics** + [ ## 前提条件 ](#get-started-create-workflow-prerequisites) + [ ## ステップ 1: ワークフローの作成と構成 ](#get-started-create-workflow-create) + [ ## ステップ 2: コミットを使用したワークフローの保存 ](#get-started-create-workflow-commit) + [ ## ステップ 3: 実行結果の表示 ](#get-started-create-workflow-results) + [ ## （オプション）ステップ 4: クリーンアップする ](#get-started-create-workflow-cleanup) ## 前提条件開始する前に: + CodeCatalyst **スペース**が必要です。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。 + CodeCatalyst スペースには、次の名前の空のプロジェクトが必要です。 ``` codecatalyst-project ``` 詳細については、「[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)」を参照してください。 + プロジェクトには、次の名前の CodeCatalyst **リポジトリ**が必要です。 ``` codecatalyst-source-repository ``` 詳細については、「[ソースリポジトリを作成する](source-repositories-create.md)」を参照してください。 **注記** 既存のプロジェクトとソースリポジトリがある場合はそれらを使用できますが、新しいものを作成すると、このチュートリアルの最後にクリーンアップが容易になります。 ## ステップ 1: ワークフローの作成と構成このステップでは、変更が行われたときにソースコードを自動的に構築してテストするワークフローの作成と構成を行います。 **ワークフローを作成するには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフローを作成]** を選択します。 CodeCatalyst コンソールの YAML エディタにワークフロー定義ファイルが表示されます。 **ワークフローを構成するには** ワークフローは、**ビジュアル**エディタまたは **YAML** エディタで構成できます。まずは YAML エディタを使用し、その後ビジュアルエディタに切り替えましょう。 1. **[\$1 アクション]** を選択すると、ワークフローに追加できるワークフローアクションのリストが表示されます。 1. **[ビルド]** アクションで**[\$1]** を選択し、アクションの YAML をワークフロー定義ファイルに追加します。これでワークフローは次のようになります。 ``` Name: Workflow_fe47 SchemaVersion: "1.0" # Optional - Set automatic triggers. Triggers: - Type: Push Branches: - main # Required - Define action configurations. Actions: Build_f0: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource # This specifies that the action requires this workflow as a source Outputs: AutoDiscoverReports: Enabled: true # Use as prefix for the report files ReportNamePrefix: rpt Configuration: Steps: - Run: echo "Hello, World!" - Run: echo "" >> report.xml - Run: echo "" >> report.xml - Run: echo "" >> report.xml ``` ワークフローでは、`Build_f0` アクションを実行しているコンピューティングマシンに `WorkflowSource` ソースリポジトリ内のファイルをコピーし、`Hello, World!` をログに出力し、コンピューティングマシン上のテストレポートを検出して、CodeCatalyst コンソールの **[レポート]** ページに出力します。 1. **[ビジュアル]** を選択し、ビジュアルエディタでワークフロー定義ファイルを表示します。ビジュアルエディタのフィールドでは、YAML エディタに表示される YAML プロパティを構成できます。 ## ステップ 2: コミットを使用したワークフローの保存このステップでは変更を保存します。ワークフローはリポジトリに `.yaml` ファイルとして保存されるため、コミットで変更を保存します。 **ワークフローの変更をコミットするには** 1. (任意) **[検証]** を選択して、ワークフローの YAML コードが有効であることを確認します。 1. **[コミット]** を選択します。 1. **[ワークフローファイル名]** で、**my-first-workflow** などのワークフロー構成ファイルの名前を入力します。 1. **[コミットメッセージ]** で、**create my-first-workflow.yaml** などのコミットを区別するメッセージを入力します。 1. **[リポジトリ]** で、ワークフローを保存するリポジトリを選択します (`codecatalyst-repository`)。 1. **[ブランチ名]** で、ワークフローを保存するブランチを選択します (`main`)。 1. **[コミット]** を選択します。新しいワークフローがワークフローのリストに表示されます。表示されるまでにしばらくかかることがあります。ワークフローはコミットで保存され、ワークフローにはコードプッシュトリガーが構成されているため、ワークフローの保存によりワークフロー実行が自動的に開始されます。 ## ステップ 3: 実行結果の表示このステップでは、コミットから開始された実行に移動し、結果を表示します。 **実行結果を表示するには** 1. ワークフローの名前を選択します (例: `Workflow_fe47`)。ソースリポジトリのラベル (**WorkflowSource**) とビルドアクション **(Build\$1f0** など) が表示されているワークフロー図。 1. ワークフロー実行図で、ビルドアクション (**Build\$1f0** など) を選択します。 1. **[ログ]**、**[レポート]**、**[構成]**、**[変数]** の各タブの内容を確認します。これらのタブにはビルドアクションの結果が表示されます。詳細については、「[ビルドアクションの結果の表示](build-view-results.md)」を参照してください。 ## （オプション）ステップ 4: クリーンアップするこのステップでは、このチュートリアルで作成したリソースをクリーンアップします。 **リソースを削除するには** + このチュートリアル用に新しいプロジェクトを作成した場合は、削除します。手順については、「[プロジェクトの削除](projects-delete.md)」を参照してください。プロジェクトを削除すると、ソースリポジトリとワークフローも削除されます。 # ワークフローを使用したビルド [[CodeCatalyst ワークフロー]](workflow.md) を使用すると、アプリケーションやその他のリソースをビルドできます。 **Topics** + [ ## アプリケーションをビルドする方法 ](#build-how-to) + [ ## ビルドアクションの利点 ](#build-benefits) + [ ## ビルドアクションの代替方法 ](#build-alternatives) + [ # ビルドアクションの追加 ](build-add-action.md) + [ # ビルドアクションの結果の表示 ](build-view-results.md) + [ # チュートリアル: Amazon S3 にアーティファクトをアップロードする ](build-deploy.md) + [ # ビルドおよびテストアクション YAML ](build-action-ref.md) ## アプリケーションをビルドする方法 CodeCatalyst でアプリケーションまたはリソースをビルドするには、まずワークフローを作成し、その中にビルドアクションを指定します。 *ビルドアクション*は、ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行うビルディングブロックです。 CodeCatalyst コンソールのビジュアルエディタまたは YAML エディタを使用して、ワークフローにビルドアクションを追加します。アプリケーションまたはリソースをビルドするための大まかなステップは次のとおりです。 **アプリケーションをビルドするには (概要レベルのタスク)** 1. CodeCatalyst では、ビルドするアプリケーションの**ソースコードを追加します**。詳細については、「[CodeCatalyst のプロジェクト用リポジトリにソースコードを保存する](source-repositories.md)」を参照してください。 1. CodeCatalyst では、**ワークフローを作成します**。ワークフローでは、アプリケーションをビルド、テスト、デプロイする方法を定義します。詳細については、「[初めてのワークフロー](workflows-getting-started.md)」を参照してください。 1. (オプション) ワークフローで、ワークフローを自動的に開始するイベントを示す**リガーを追加します**。詳細については、[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)を参照してください。 1. ワークフローでは、アプリケーションまたはリソースソースコードをコンパイルしてパッケージ化する**ビルドアクション**を追加します。これらの目的でテストまたはデプロイアクションを使用しない場合は、ビルドアクションの実行ユニットテスト、レポートの生成、アプリケーションのデプロイを任意で行うこともできます。テストとデプロイアクションの詳細については、「[ビルドアクションの追加](build-add-action.md)」を参照してください。 1. (オプション) ワークフローで、**テストアクション**と**デプロイアクション**を追加し、アプリケーションまたはリソースをテストおよびデプロイします。Amazon ECS など、さまざまなターゲットにアプリケーションをデプロイするための事前設定されたアクションを複数選択できます。詳細については「[ワークフローを使用したテストワークフローを使用したテスト](test-workflow-actions.md)」および「[ワークフローを使用したデプロイワークフローを使用したデプロイ](deploy.md)」を参照してください。 1. **ワークフローの開始**は、手動で行うか、トリガーを介して自動で行います。ワークフローは、ビルド、テスト、デプロイアクションを順番に実行して、アプリケーションとリソースをターゲットにビルド、テスト、デプロイします。詳細については、「[手動でのワークフロー実行の開始](workflows-manually-start.md)」を参照してください。 ## ビルドアクションの利点ワークフロー内でビルドアクションを使用すると、次の利点があります。 + **完全マネージド型** – ビルドアクションにより、独自のビルドサーバーをセットアップ、パッチ適用、更新、管理する必要がなくなります。 + **オンデマンド** – ビルドアクション　が、ビルドのニーズに合わせてオンデマンドでスケーリングします。料金は、使用したビルド分数に対してのみ発生します。詳細については、「[コンピューティングイメージとランタイムイメージの構成](workflows-working-compute.md)」を参照してください。 + **設定不要** – CodeCatalyst には、ビルドアクションを含むすべてのワークフローアクションを実行するために使用される、事前にパッケージ化されたランタイム環境の Docker イメージが含まれています。これらのイメージには、 AWS CLI や Node.js などのアプリケーションを構築するための便利なツールが事前設定されています。CodeCatalyst は、パブリックまたはプライベートレジストリから指定したビルドイメージを使用するように設定できます。詳細については、「[ランタイム環境イメージの指定](build-images.md)」を参照してください。 ## ビルドアクションの代替方法ビルドアクションを使用してアプリケーションをデプロイする場合は、代わりに CodeCatalyst *デプロイアクション*の使用を検討してください。デプロイアクションは、ビルドアクションを使用している場合に手動で書き込む必要があるバックグラウンド設定を実行します。使用可能なデプロイアクションの詳細については、「[デプロイアクションの一覧](deploy.md#deploy-concepts-action-supported)」を参照してください。 AWS CodeBuild を使用してアプリケーションを構築することもできます。詳細については、「[What is CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)」を参照してください。 # ビルドアクションの追加 CodeCatalyst ワークフローにビルドアクションを追加するには、次の手順に従います。 ------ #### [ Visual ] **ビジュアルエディタを使用してビルドアクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. **[アクション]** を選択します。 1. **[アクション]** で **[ビルド]** を選択します。 1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[ビルドおよびテストアクション YAML](build-action-ref.md)」を参照してください。このリファレンスでは、YAML エディタとビジュアルエディタの両方に表示される各フィールド (および対応する YAML プロパティ値) に関する詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用してビルドアクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. **[アクション]** を選択します。 1. **[アクション]** で **[ビルド]** を選択します。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[ビルドおよびテストアクション YAML](build-action-ref.md)」に記載されています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ ## ビルドアクションの定義ビルドアクションは、ワークフロー定義ファイル内の一連の YAML プロパティとして定義されます。これらのプロパティの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」の「[ビルドおよびテストアクション YAML](build-action-ref.md)」を参照してください。 # ビルドアクションの結果の表示生成されたログ、レポート、変数など、ビルドアクションの結果を表示するには、以下の手順に従います。 **ビルドアクションの結果を表示する方法** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. ワークフロー図で、ビルドアクションの名前を選択します。例えば、**[ビルド] ** です。 1. ビルド実行のログを表示するには、**[ログ]** を選択します。さまざまなビルドフェーズのログが表示されます。必要に応じてログを展開または折りたたむことができます。 1. ビルドアクションによって生成されたテストレポートを表示するには、**[レポート]** を選択するか、ナビゲーションペインで **[レポート]** を選択します。詳細については、「[品質レポートのタイプ](test-workflow-actions.md#test-reporting)」を参照してください。 1. ビルドアクションに使用する設定の詳細を表示するには、**[設定]** タブを選択します。詳細については、「[ビルドアクションの追加](build-add-action.md)」を参照してください。 1. ビルドアクションで使用される変数を表示するには、**[変数]** を選択します。詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 # チュートリアル: Amazon S3 にアーティファクトをアップロードするこのチュートリアルでは、いくつかの [[ビルドアクション]](workflows-concepts.md#workflows-concepts-actions) を含む Amazon CodeCatalyst [ワークフロー](workflows-concepts.md#workflows-concepts-workflows)を使用して、Amazon S3 バケットにアーティファクトをアップロードする方法について説明します。これらのアクションは、ワークフローの開始時に連続して実行されます。最初のビルドアクションは、`Hello.txt` と `Goodbye.txt` の 2 つのファイルを生成し、それらをビルドアーティファクトにバンドルします。2 番目のビルドアクションは、アーティファクトを Amazon S3 にアップロードします。コミットをソースリポジトリにプッシュするたびに実行されるようにワークフローを設定します。 **Topics** + [ ## 前提条件 ](#build-deploy-tut-prereqs) + [ ## ステップ 1: AWS ロールを作成する ](#build-deploy-tut-role) + [ ## ステップ 1: Amazon S3 バケットを作成する ](#build-deploy-tut-artifact) + [ ## ステップ 3: ソースレポジトリを作成する ](#deploy-tut-lambda-cfn-source) + [ ## ステップ 4: ワークフローを作成する ](#build-deploy-tut-workflow.title) + [ ## ステップ 5: 結果の検証 ](#build-deploy.s3.verify) + [ ## クリーンアップ ](#deploy-tut-lambda-cfn-clean-up) ## 前提条件開始するには、以下が必要です。 + 接続された AWS アカウントを持つ CodeCatalyst **スペース** が必要です。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。 + スペースには、次の名前の空のプロジェクトが必要です。 ``` codecatalyst-artifact-project ``` このプロジェクトを作成するには、**[ゼロから開始]** オプションを使用します。詳細については、「[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)」を参照してください。 + プロジェクトには、以下と呼ばれる CodeCatalyst **[環境]** が必要です。 ``` codecatalyst-artifact-environment ``` この環境を次のように設定します。 + **[開発]** などの任意のタイプを選択します。 + AWS アカウントにを接続します。 + **[デフォルトの IAM ロール]** で、任意のロールを選択します。後で別のロールを指定します。詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」を参照してください。 ## ステップ 1: AWS ロールを作成するこのステップでは、後でワークフローのビルドアクションに割り当てる IAM AWS ロールを作成します。このロールは、CodeCatalyst ビルドアクションに、 AWS アカウントにアクセスしてアーティファクトが保存される Amazon S3 に書き込むアクセス許可を付与します。ロールは、**[ビルドロール]** と呼ばれます。 **注記** 別のチュートリアル用に作成したビルドロールが既にある場合は、このチュートリアルでも使用できます。以下の手順で示されているアクセス許可と信頼ポリシーがあることを確認してください。 IAM ロールの詳細については、「 *AWS AWS Identity and Access Management ユーザーガイド*」の[「IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」を参照してください。 **ビルドロールを作成するには** 1. ロールのポリシーを以下の手順で作成します。 1. にサインインします AWS。 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. ナビゲーションペインで、**ポリシー** を選択してください。 1. **[Create policy]** (ポリシーを作成) を選択します。 1. **JSON** タブを選択します。 1. 既存のコードを削除します。 1. 次のコードを貼り付けます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:ListBucket" ], "Resource": "*" } ] } ``` ------ **注記** ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。 ``` "Resource": "*" ``` 1. [**Next: Tags (次へ: タグ)**] を選択します。 1. **[次へ: レビュー]** を選択します。 1. **[名前]** に次のように入力します。 ``` codecatalyst-s3-build-policy ``` 1. [**Create policy**] (ポリシーの作成) を選択します。これで、アクセス許可ポリシーが作成されました。 1. 次のようにビルドロールを作成します。 1. ナビゲーションペインで **ロール** を選択してから、**ロールを作成する** を選択します。 1. **[カスタム信頼ポリシー]** を選択します。 1. 既存のカスタム信頼ポリシーを削除します。 1. 次の信頼ポリシーを追加します。 1. [**次へ**] を選択します。 1. **[アクセス許可ポリシー]** で `codecatalyst-s3-build-policy` を検索し、チェックボックスをオンにします。 1. [**次へ**] を選択します。 1. **[ロール名]** には、次のように入力します。 ``` codecatalyst-s3-build-role ``` 1. **[ロールの説明]** には、次のように入力します。 ``` CodeCatalyst build role ``` 1. [**ロールの作成**] を選択してください。これで、信頼ポリシーとアクセス許可ポリシーを使用してビルドロールが作成されました。 ## ステップ 1: Amazon S3 バケットを作成するこのステップでは、`Hello.txt` および `Goodbye.txt` アーティファクトをアップロードする Amazon S3 バケットを作成します。 **Amazon S3 バケットを作成するには** 1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。 1. メインペインで、**[バケットを作成]** を選択します。 1. **[バケット名]** に、次のように入力します。 ``` codecatalyst-artifact-bucket ``` 1. **[AWS リージョン]** で、リージョンを選択します。このチュートリアルは、**[米国西部 (オレゴン) us-west-2]** を選択していることを前提としています。Amazon S3 がサポートしているリージョンについては、「*AWS 全般のリファレンス*」の「[Amazon Simple Storage Service エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/s3.html)」を参照してください。 1. ページ下部にある **[バケットを作成]** ボタンを選択します。 1. 作成したバケットの名前をコピーします。例: ``` codecatalyst-artifact-bucket ``` これで、米国西部 (オレゴン) us-west-2 リージョンで **codecatalyst-artifact-bucket** という名前のバケットが作成されました。 ## ステップ 3: ソースレポジトリを作成するこのステップでは、CodeCatalyst に空のソースリポジトリを作成します。このリポジトリは、チュートリアルのワークフロー定義ファイルを保存するために使用されます。ソースリポジトリの詳細については、「[ソースリポジトリを作成する](source-repositories-create.md)」を参照してください。 **ソースリポジトリを作成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクト「`codecatalyst-artifact-project`」に移動します。 1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。 1. **[リポジトリの追加]** を選択し、**[リポジトリの作成]** を選択します。 1. **[リポジトリ名]** に次のように入力します。 ``` codecatalyst-artifact-source-repository ``` 1. **[作成]** を選択します。これで、`codecatalyst-artifact-source-repository` というリポジトリが作成されました。 ## ステップ 4: ワークフローを作成するこのステップでは、連続して実行される次の構成要素で構成されるワークフローを作成します。 + トリガー – このトリガーは、ソースリポジトリに変更をプッシュすると、ワークフローを自動的に開始します。詳細については、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + ビルドアクション「`GenerateFiles`」 - トリガー時に、`GenerateFiles` アクションは 2 つのファイル「`Hello.txt`」と「`Goodbye.txt`」を作成し、出力アーティファクト「`codecatalystArtifact`」にパッケージ化します。 + 別のビルドアクション「`Upload`」- `GenerateFiles` アクションが完了すると、`Upload` アクションは AWS CLI コマンド `aws s3 sync` を実行して、`codecatalystArtifact` とソースリポジトリ内のファイルを Amazon S3 バケットにアップロードします。 AWS CLI は CodeCatalyst コンピューティングプラットフォームにプリインストールおよび事前設定されているため、インストールまたは設定する必要はありません。 CodeCatalyst コンピューティングプラットフォームでパッケージ化されたソフトウェアの詳細については、「[ランタイム環境イメージの指定](build-images.md)」を参照してください。コマンドの詳細については、`aws s3 sync`「コマンド*AWS CLI リファレンス*」の AWS CLI[「同期](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html)」を参照してください。ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。 **ワークフローを作成するには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフローを作成]** を選択します。 1. YAML サンプルコードを削除します。 1. 次の YAML コードを追加します。 **注記** 次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。このセクションを省略する場合は、環境の **[デフォルト IAM ロール]** フィールドで指定されたロールに、[ステップ 1: AWS ロールを作成する](#build-deploy-tut-role) で記述されているアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 ``` Name: codecatalyst-artifact-workflow SchemaVersion: 1.0 Triggers: - Type: Push Branches: - main Actions: GenerateFiles: Identifier: aws/build@v1 Configuration: Steps: # Create the output files. - Run: echo "Hello, World!" > "Hello.txt" - Run: echo "Goodbye!" > "Goodbye.txt" Outputs: Artifacts: - Name: codecatalystArtifact Files: - "**/*" Upload: Identifier: aws/build@v1 DependsOn: - GenerateFiles Environment: Name: codecatalyst-artifact-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-s3-build-role Inputs: Artifacts: - codecatalystArtifact Configuration: Steps: # Upload the output artifact to the S3 bucket. - Run: aws s3 sync . s3://codecatalyst-artifact-bucket ``` 上記のコードで、以下を置き換えます。 + [[前提条件](#build-deploy-tut-prereqs)] で作成した環境の名前を持つ *[codecatalyst-artifact-environment]*。 + [前提条件](#build-deploy-tut-prereqs) で作成したアカウント接続の名前を持つ *[codecatalyst-account-connection]*。 + [ステップ 1: AWS ロールを作成する](#build-deploy-tut-role) で作成したビルドロールの名前を持つ、*[codecatalyst-s3-build-role]*。 + [ステップ 1: Amazon S3 バケットを作成する](#build-deploy-tut-artifact) で作成した Amazon S3 の名前を持つ *[codecatalyst-artifact-bucket]*。このファイルのプロパティの詳細については、「[ビルドおよびテストアクション YAML](build-action-ref.md)」を参照してください。 1. (任意) **[検証]** を選択して、コミットする前に YAML コードが有効であることを確認します。 1. **[コミット]** を選択します。 1. **[ワークフローをコミット]** ダイアログボックスで、次のように入力します。 1. **[ワークフローファイル名]** の場合、デフォルトの「`codecatalyst-artifact-workflow`」のままにします。 1. **[コミットメッセージ]** には、次のように入力します。 ``` add initial workflow file ``` 1. **[リポジトリ]** で、**[codecatalyst-artifact-source-repository]** を選択します。 1. **[ブランチ名]** で、**[main]** を選択します。 1. **[コミット]** を選択します。これでワークフローが作成されました。ワークフローの先頭で定義されているトリガーにより、ワークフローの実行が自動的に開始されます。具体的には、`codecatalyst-artifact-workflow.yaml` ファイルをソースリポジトリにコミット (およびプッシュ) すると、トリガーによってワークフローの実行が開始します。 **ワークフロー実行の進行状況を確認するには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. 先ほど作成したワークフロー「`codecatalyst-artifact-workflow`」を選択します。 1. **[GenerateFiles]** を選択すると、最初のビルドアクションの進行状況が表示されます。 1. **[アップロード]** を選択して、2 番目のビルドアクションの進行状況を確認します。 1. **[アップロード]** アクションが完了したら、以下を実行します。 + ワークフローの実行が成功したら、次の手順に進みます。 + ワークフローの実行が失敗した場合は、**[ログ]** を選択して問題をトラブルシューティングします。 ## ステップ 5: 結果の検証ワークフローを実行したら、Amazon S3 サービスに移動し、*[codecatalyst-artifact-bucket]* バケットを確認します。これで、次のファイルとフォルダが含まれるようになりました。 ``` . |— .aws/ |— .git/ |Goodbye.txt |Hello.txt |REAME.md ``` `Goodbye.txt` および `Hello.txt` ファイルは、`codecatalystArtifact` アーティファクトの一部であったため、アップロードされました。`.aws/`、`.git/`、`README.md` ファイルはソースリポジトリにあったため、アップロードされました。 ## クリーンアップ CodeCatalyst およびでクリーンアップ AWS して、これらのサービスに対して課金されないようにします。 **CodeCatalyst でクリーンアップするには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. `codecatalyst-artifact-source-repository` ソースリポジトリを削除します。 1. `codecatalyst-artifact-workflow` ワークフローを選択します。 **でクリーンアップするには AWS** 1. Amazon S3 で次のようにクリーンアップします。 1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。 1. `codecatalyst-artifact-bucket` バケットのファイルを削除します。 1. `codecatalyst-artifact-bucket` バケットを削除します。 1. IAM で次のようにクリーンアップします。 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. `codecatalyst-s3-build-policy` を削除します。 1. `codecatalyst-s3-build-role` を削除します。 # ビルドおよびテストアクション YAML 以下は、ビルドアクションとテストアクションの YAML 定義です。YAML プロパティはとても似通っているため、2 つのアクションには 1 つのリファレンスがあります。このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。次のコード内で YAML プロパティを選択すると、説明が表示されます。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティと共に一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. action-name: Identifier: aws/build@v1 | aws/managed-test@v1 DependsOn: - dependent-action-name-1 Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Caching: FileCaching: key-name-1: Path: file1.txt RestoreKeys: - restore-key-1 Inputs: Sources: - source-name-1 - source-name-2 Artifacts: - artifact-name Variables: - Name: variable-name-1 Value: variable-value-1 - Name: variable-name-2 Value: variable-value-2 Outputs: Artifacts: - Name: output-artifact-1 Files: - build-output/artifact-1.jar - "build-output/build*" - Name: output-artifact-2 Files: - build-output/artifact-2.1.jar - build-output/artifact-2.2.jar Variables: - variable-name-1 - variable-name-2 AutoDiscoverReports: Enabled: true | false ReportNamePrefix: AutoDiscovered IncludePaths: - "**/*" ExcludePaths: - node_modules/cdk/junit.xml SuccessCriteria: PassRate: percent LineCoverage: percent BranchCoverage: percent Vulnerabilities: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisBug: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisSecurity: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisQuality: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisFinding: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number Reports: report-name-1: Format: format IncludePaths: - "*.xml" ExcludePaths: - report2.xml - report3.xml SuccessCriteria: PassRate: percent LineCoverage: percent BranchCoverage: percent Vulnerabilities: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisBug: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisSecurity: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisQuality: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number StaticAnalysisFinding: Severity: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL Number: whole-number Configuration: Container: Registry: registry Image: image Steps: - Run: "step 1" - Run: "step 2" Packages: NpmConfiguration: PackageRegistries: - PackagesRepository: package-repository Scopes: - "@scope" ExportAuthorizationToken: true | false ``` ## action-name (必須) アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。対応する UI: [設定] タブ/**[アクション名]** ## Identifier (*action-name*/**Identifier**) アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。ビルドアクションに `aws/build@v1` を使用します。テストアクションに `aws/managed-test@v1` を使用します。対応する UI: ワークフロー図/Action-name/*aws/build@v1\$1aws/managed-test@v1* ラベル ## DependsOn (*action-name*/**DependsOn**) (オプション) このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。対応する UI: [入力] タブ/**[依存 - オプション]** ## Compute (*action-name*/**Compute**) (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。対応する UI: *なし* ## Type (*action-name*/Compute/**Type**) ([Compute](#build.computename) が含まれている場合は必須) コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。 + **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ) アクション実行時の柔軟性を目的として最適化されています。 + **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ) アクションの起動速度を最適化しました。コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。対応する UI: [設定] タブ/**[コンピューティングタイプ]** ## Fleet (*action-name*/Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。対応する UI: [設定] タブ/**[コンピューティングフリート]** ## Timeout (*action-name*/**Timeout**) (オプション) CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。対応する UI: [設定] タブ/**[タイムアウト - オプション]** ## Environment (*action-name*/**Environment**) (オプション) アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウントおよびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用してに接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。 **注記** デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。環境タグ付けの詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: [設定] タブ/**[環境]** ## Name (*action-name*/Environment/**Name**) (オプション) アクションに関連付ける既存の環境の名前を指定します。対応する UI: [設定] タブ/**[環境]** ## Connections (*action-name*/Environment/**Connections**) (オプション) アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。アカウント接続を指定しない場合: + アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 + デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** ## Name (*action-name*/Environment/Connections/**Name**) ([Connections](#build.environment.connections) が含まれている場合は必須) アカウント接続の名前を指定します。対応する UI: [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** ## Role (*action-name*/Environment/Connections/**Role**) ([Connections](#build.environment.connections) が含まれている場合は必須) Amazon S3 や Amazon ECR などの AWS のサービスにアクセスして操作するために、このアクションが使用する IAM ロールの名前を指定します。このロールがスペースの AWS アカウント接続に追加されていることを確認します。アカウント接続に IAM ロールを追加するには、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。 IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーが設定されていることを確認してください。 **注記** このアクションでは、`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。 **警告** アクセス許可は、ビルドアクションとテストアクションに必要なアクセス許可に制限します。より広範なアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。対応する UI: [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** ## Caching (*action-name*/**Caching**) (オプション) キャッシュを指定してディスク上のファイルを保存し、後続のワークフロー実行でそのキャッシュから復元できるセクションです。ファイルキャッシングの詳細については、「[ワークフロー実行間のファイルのキャッシュ](workflows-caching.md)」を参照してください。対応する UI: [設定] タブ/**[ファイルキャッシュ - オプション]** ## FileCaching (*action-name*/Caching/**FileCaching**) (オプション) 一連のキャッシュの設定を指定するセクションです。対応する UI: [設定] タブ/[ファイルキャッシュ - オプション]/**[キャッシュを追加]** ## key-name-1 (*action-name*/Caching/FileCaching/***key-name-1***) (オプション) プライマリキャッシュプロパティ名の名前を指定します。キャッシュプロパティ名は、ワークフロー内で一意である必要があります。各アクションには、`FileCaching` に最大 5 つのエントリを含めることができます。対応する UI: [設定] タブ/[ファイルキャッシュ - オプション]/[キャッシュを追加]/**[キー]** ## Path (*action-name*/Caching/FileCaching/*key-name-1*/**Path**) (オプション) キャッシュの関連するパスを指定します。対応する UI: [設定] タブ/[ファイルキャッシュ - オプション]/[キャッシュを追加]/**[パス]** ## RestoreKeys (*action-name*/Caching/FileCaching/*key-name-1*/**RestoreKeys**) (オプション) プライマリキャッシュプロパティが見つからない場合にフォールバックとして使用する復元キーを指定します。復元キー名は、ワークフロー内で一意である必要があります。各キャッシュには、`RestoreKeys` に最大 5 つのエントリを含めることができます。対応する UI: [設定] タブ/[ファイルキャッシュ - オプション]/[キャッシュを追加]/**[キーの復元 - オプション]** ## Inputs (*action-name*/**Inputs**) (オプション) `Inputs` セクションでは、ワークフローの実行中にアクションに必要なデータ定義します。 **注記** ビルドアクションまたはテストアクションごとに最大 4 つの入力 (1 つのソースと 3 つのアーティファクト) が許可されます。変数はこの合計にはカウントされません。異なる入力 (ソースとアーティファクトなど) にあるファイルを参照する必要がある場合、ソース入力はプライマリ入力で、アーティファクトはセカンダリ入力になります。セカンダリ入力内のファイルへの参照には、プライマリからファイルを区別するための特別なプレフィックスが付きます。詳細については、「[例: 複数のアーティファクトでのファイルの参照](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)」を参照してください。対応する UI: **[入力] タブ** ## Sources (*action-name*/Inputs/**Sources**) (オプション) アクションに必要なソースリポジトリを表すラベルを指定します。現在、サポートされているラベルは `WorkflowSource` のみです。これは、ワークフロー定義ファイルが保存されているソースリポジトリを表します。ソースを省略する場合は、`action-name/Inputs/Artifacts` で少なくとも 1 つの入力アーティファクトを指定する必要があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。対応する UI: *なし* ## Artifacts - input (*action-name*/Inputs/**Artifacts**) (オプション) このアクションへの入力として提供する以前のアクションのアーティファクトを指定します。これらのアーティファクトは、前のアクションで出力アーティファクトとして既に定義されている必要があります。入力アーティファクトを指定しない場合は、`action-name/Inputs/Sources` で少なくとも 1 つのソースリポジトリを指定する必要があります。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **注記** **[アーティファクト - オプション]** のドロップダウンリストが使用できない場合 (ビジュアルエディタ)、または YAML の検証時にエラーが発生する場合 (YAML エディタ)、アクションが 1 つの入力のみをサポートしていることが原因である可能性があります。この場合はソース入力を削除してみてください。対応する UI: [入力] タブ/**[アーティファクト - オプション]** ## Variables - input (*action-name*/Inputs/**Variables**) (オプション) アクションで使用できるようにしたい入力変数を定義する名前と値のペアのシーケンスを指定します。変数名に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、変数名で特殊文字とスペースを有効にすることはできません。変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。対応する UI: [入力] タブ/**[変数 - オプション]** ## Outputs (*action-name*/**Outputs**) (オプション) ワークフローの実行中にアクションによって出力されるデータを定義します。対応する UI: **[出力]** タブ ## Artifacts - output (*action-name*/Outputs/**Artifacts**) (オプション) アクションによって生成されるアーティファクトの名前を指定します。アーティファクト名はワークフロー内で一意でなければならず、英数字 (a～z、A～Z、0～9) とアンダースコア (\$1) しか使用できません。スペース、ハイフン (-)、その他の特殊文字は使用できません。引用符を使用して、出力アーティファクト名でスペース、ハイフン、その他の特殊文字を有効にすることはできません。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [出力] タブ/**[アーティファクト]** ## Name (*action-name*/Outputs/Artifacts/**Name**) ([Artifacts - output](#build.outputs.artifacts) が含まれている場合は必須) アクションによって生成されるアーティファクトの名前を指定します。アーティファクト名はワークフロー内で一意でなければならず、英数字 (a～z、A～Z、0～9) とアンダースコア (\$1) しか使用できません。スペース、ハイフン (-)、その他の特殊文字は使用できません。引用符を使用して、出力アーティファクト名でスペース、ハイフン、その他の特殊文字を有効にすることはできません。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [出力] タブ/[アーティファクト]/[新しい出力]/**[ビルドアーティファクト名]** ## Files (*action-name*/Outputs/Artifacts/**Files**) ([Artifacts - output](#build.outputs.artifacts) が含まれている場合は必須) CodeCatalyst がアクションによって出力されるアーティファクトに含めるファイルを指定します。これらのファイルは、実行時にワークフローアクションによって生成され、ソースリポジトリでも使用できます。ファイルパスは、ソースリポジトリまたは前のアクションからのアーティファクトに設定でき、ソースリポジトリまたはアーティファクトルートを基準とすることができます。glob パターンを使用してパスを指定できます。例: + ビルドまたはソースリポジトリの場所のルートにある 1 つのファイルを指定するには、`my-file.jar` を使用します。 + サブディレクトリ内の 1 つのファイルを指定するには、`directory/my-file.jar` または `directory/subdirectory/my-file.jar` を使用します。 + すべてのファイルを指定するには、`"**/*"` を使用します。glob パターン `**` は、任意の数のサブディレクトリにマッチすることを示します。 + `directory` という名前のディレクトリ内のすべてのファイルとディレクトリを指定するには、`"directory/**/*"` を使用します。glob パターン `**` は、任意の数のサブディレクトリにマッチすることを示します。 + `directory` という名前のディレクトリ内のすべてのファイルを指定するが、そのサブディレクトリを含めないようにするには、`"directory/*"` を使用します。 **注記** ファイルパスに 1 つ以上のアスタリスク (`*`) またはその他の特殊文字が含まれている場合は、パスを二重引用符 (`""`) で囲みます。特殊文字の詳細については、「[構文ガイドラインと規則](workflow-reference.md#workflow.terms.syntax.conv)」を参照してください。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **注記** 場合によっては、ファイルパスにプレフィックスを追加して、どのアーティファクトまたはソースにあるのかを示す必要があります。詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」および「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。対応する UI: [出力] タブ/[アーティファクト]/**[新しい出力]/[ビルドで生成されるファイル]** ## Variables - output (*action-name*/Outputs/**Variables**) (オプション) 後続のアクションで使用できるように、アクションがエクスポートする変数を指定します。変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。対応する UI: [出力] タブ/[変数]/**[変数を追加]** ## variable-name-1 (*action-name*/Outputs/Variables/*variable-name-1*) (オプション) アクションでエクスポートする変数の名前を指定します。この変数は、同じアクションの `Inputs` セクションか `Steps` セクションであらかじめ定義されている必要があります。変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。対応する UI: [出力] タブ/[変数]/[変数を追加]/**[名前]** ## AutoDiscoverReports (*action-name*/Outputs/**AutoDiscoverReports**) (オプション) 自動検出機能の設定を定義します。自動検出を有効にすると、CodeCatalyst はアクションに渡されたすべての `Inputs` と、アクション自体によって生成されたすべてのファイルを検索し、テストレポート、コードカバレッジレポート、ソフトウェアコンポジション分析 (SCA) レポートを探します。検出された各レポートは、CodeCatalyst レポートに変換されます。*CodeCatalyst レポート*は、CodeCatalyst サービスに完全に統合されており、CodeCatalyst コンソールを介して表示および操作できます。 **注記** デフォルトでは、自動検出機能はすべてのファイルを検査します。[IncludePaths](#build.reports.includepaths) または [ExcludePaths](#build.reports.excludepaths) プロパティを使用して、検査するファイルを制限できます。対応する UI: [出力] タブ/[レポート]/**[自動検出レポート]** ## Enabled (*action-name*/Outputs/AutoDiscoverReports/**Enabled**) (オプション) 自動検出機能を有効または無効にします。有効な値は `true` または `false` です。 `Enabled` を省略した場合、デフォルトは `true` です。対応する UI: [出力] タブ/[レポート]/**[自動検出レポート]** ## ReportNamePrefix (*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**) ([AutoDiscoverReports](#build.outputs.autodiscover) が含まれ、有効になっている場合は必須) 関連する CodeCatalyst レポートに名前を付けるために、CodeCatalyst が検出したすべてのレポートに付加するプレフィックスを指定します。例えば、プレフィックスを `AutoDiscovered` に指定し、CodeCatalyst が 2 つのテストレポート、`TestSuiteOne.xml`、`TestSuiteTwo.xml` を自動的に検出する場合、関連する CodeCatalyst レポートには `AutoDiscoveredTestSuiteOne` と `AutoDiscoveredTestSuiteTwo` という名前が付けられます。対応する UI: [出力] タブ/[レポート]/**[プレフィックス名]** ## IncludePaths (*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**) または (*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**) ([AutoDiscoverReports](#build.outputs.autodiscover) が含まれ、有効になっている場合、または [Reports](#test.configuration.reports) が含まれている場合は必須) CodeCatalyst が未加工レポートを検索するときに含めるファイルとファイルパスを指定します。例えば、`"/test/report/*"` を指定すると、CodeCatalyst は `/test/report/*` ディレクトリを検索するアクションで使用される[ビルドイメージ](build-images.md)全体を検索します。そのディレクトリが見つかると、CodeCatalyst はそのディレクトリ内のレポートを検索します。 **注記** ファイルパスに 1 つ以上のアスタリスク (`*`) またはその他の特殊文字が含まれている場合は、パスを二重引用符 (`""`) で囲みます。特殊文字の詳細については、「[構文ガイドラインと規則](workflow-reference.md#workflow.terms.syntax.conv)」を参照してください。このプロパティを省略した場合、デフォルトは `"**/*"` です。つまり、検索にはすべてのパスのすべてのファイルが含まれます。 **注記** 手動で設定するレポートの場合、`IncludePaths` は単一のファイルに一致する glob パターンである必要があります。対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[パスを含める/除外する]/**[パスを含める]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[パスを含める/除外する]/**[パスを含める]** ## ExcludePaths (*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**) または (*action-name*/Outputs/Reports/*report-name-1*/**ExcludePaths**) (オプション) 未加工レポートを検索するときに CodeCatalyst が除外するファイルとファイルパスを指定します。例えば、`"/test/my-reports/**/*"` を指定した場合、CodeCatalyst は `/test/my-reports/` ディレクトリ内のファイルを検索しません。ディレクトリ内のすべてのファイルを無視するには、`**/*` glob パターンを使用します。 **注記** ファイルパスに 1 つ以上のアスタリスク (`*`) またはその他の特殊文字が含まれている場合は、パスを二重引用符 (`""`) で囲みます。特殊文字の詳細については、「[構文ガイドラインと規則](workflow-reference.md#workflow.terms.syntax.conv)」を参照してください。対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[パスを含める/除外する]/**[パスを除外する]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[パスを含める/除外する]/**[パスを除外する]** ## SuccessCriteria (*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**) または (*action-name*/Outputs/Reports/*report-name-1*/**SuccessCriteria**) (オプション) テストレポート、コードカバレッジレポート、ソフトウェアコンポジション分析 (SCA) レポート、静的分析 (SA) レポートの成功基準を指定します。詳細については、「[レポートの成功基準の設定](test-config-action.md#test.success-criteria)」を参照してください。対応する UI: 出力タブ/レポート/**[成功基準]** ## PassRate (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、テストレポート内のテストに求められる合格の割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。パスレートの基準は、テストレポートにのみ適用されます。テストレポートの詳細については、「[テストレポート](test-workflow-actions.md#test-reports)」を参照してください。対応する UI: 出力タブ/レポート/成功基準/**[合格率]** ## LineCoverage (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、コードカバレッジレポート内でカバーする必要がある行の割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。ラインカバレッジ基準は、コードカバレッジレポートにのみ適用されます。コードカバレッジレポートの詳細については、「[コードカバレッジレポート](test-workflow-actions.md#test-code-coverage-reports)」を参照してください。対応する UI: 出力タブ/レポート/成功基準/**[ラインカバレッジ]** ## BranchCoverage (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、コードカバレッジレポート内でカバーする必要があるブランチの割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。ブランチカバレッジ基準は、コードカバレッジレポートにのみ適用されます。コードカバレッジレポートの詳細については、「[コードカバレッジレポート](test-workflow-actions.md#test-code-coverage-reports)」を参照してください。対応する UI: 出力タブ/レポート/成功基準/**[ブランチカバレッジ]** ## Vulnerabilities (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、SCA レポートで許容される脆弱性の数と重要度の上限を指定します。脆弱性を指定するには、以下を指定する必要があります。 + カウントに含める脆弱性の最小重要度。有効な値は、重要度が高い順に `CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。例えば、`HIGH` を選択すると、`HIGH` と `CRITICAL` の脆弱性が集計されます。 + 指定された重要度の脆弱性の最大許容数。この数を超えると、CodeCatalyst レポートは不合格としてマークされます。有効な値は整数です。脆弱性の基準は SCA レポートにのみ適用されます。SCA レポートの詳細については、「[ソフトウェア構成分析レポート](test-workflow-actions.md#test-sca-reports)」を参照してください。最小重要度を指定するには、`Severity` プロパティを使用します。脆弱性の最大数を指定するには、`Number` プロパティを使用します。対応する UI: 出力タブ/レポート/成功基準/**[脆弱性]** ## StaticAnalysisBug (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisBug**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisBug**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるように、SA レポート内で許容されるバグの最大数と重要度を指定します。バグを指定するには、以下を指定する必要があります。 + カウントするバグの最小重要度。有効な値は、重要度が高い順に、`CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。例えば、`HIGH` を選択すると、`HIGH` と `CRITICAL` のバグが集計されます。 + 指定された重要度のバグの最大許容数。この数を超えると、CodeCatalyst レポートは失敗としてマークされます。有効な値は整数です。バグ基準は、PyLint SA レポートおよび ESLint SA レポートにのみ適用されます。SA レポートの詳細については、「[静的分析レポート](test-workflow-actions.md#test-static-analysis-reports)」を参照してください。最小重要度を指定するには、`Severity` プロパティを使用します。脆弱性の最大数を指定するには、`Number` プロパティを使用します。対応する UI: [出力] タブ/[レポート]/[成功基準]/**[バグ]** ## StaticAnalysisSecurity (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisSecurity**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisSecurity**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるように、SA レポート内で許容されるセキュリティ脆弱性の最大数と重要度を指定します。セキュリティの脆弱性を指定するには、以下を指定する必要があります。 + カウントするセキュリティ脆弱性の最小重要度。有効な値は、重要度が高い順に、`CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。例えば、`HIGH` を選択すると、`HIGH` と `CRITICAL` のセキュリティ脆弱性が集計されます。 + 指定された重要度のセキュリティ脆弱性の最大許容数。この数を超えると、CodeCatalyst レポートは失敗としてマークされます。有効な値は整数です。セキュリティ脆弱性の基準は、PyLint SA レポートおよび ESLint SA レポートにのみ適用されます。SA レポートの詳細については、「[静的分析レポート](test-workflow-actions.md#test-static-analysis-reports)」を参照してください。最小重要度を指定するには、`Severity` プロパティを使用します。脆弱性の最大数を指定するには、`Number` プロパティを使用します。対応する UI: 出力タブ/レポート/成功基準/**[セキュリティの脆弱性]** ## StaticAnalysisQuality (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisQuality**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisQuality**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるように、SA レポート内で許容される品質問題の最大数と重要度を指定します。品質問題を指定するには、以下を指定する必要があります。 + カウントに含める品質問題の最小重要度。有効な値は、重要度が高い順に、`CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。例えば、`HIGH` を選択すると、`HIGH` と `CRITICAL` の品質問題が集計されます。 + 指定された重要度の品質問題の最大許容数。この数を超えると、CodeCatalyst レポートは失敗としてマークされます。有効な値は整数です。品質問題の基準は、PyLint SA レポートおよび ESLint SA レポートにのみ適用されます。SA レポートの詳細については、「[静的分析レポート](test-workflow-actions.md#test-static-analysis-reports)」を参照してください。最小重要度を指定するには、`Severity` プロパティを使用します。脆弱性の最大数を指定するには、`Number` プロパティを使用します。対応する UI: 出力タブ/レポート/成功基準/**[品質問題]** ## StaticAnalysisFinding (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**StaticAnalysisFinding**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**StaticAnalysisFinding**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるように、SA レポートで許可される検出結果の最大数と重要度を指定します。検出結果を指定するには、以下を指定する必要があります。 + カウントに含める検出結果の最小重要度。有効な値は、重要度が高い順に、`CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。例えば、`HIGH` を選択すると、`HIGH` と `CRITICAL` の結果が集計されます。 + 許可する指定された重要度の検出結果の最大数。この数を超えると、CodeCatalyst レポートは失敗としてマークされます。有効な値は整数です。検出結果は SARIF SA レポートにのみ適用されます。SA レポートの詳細については、「[静的分析レポート](test-workflow-actions.md#test-static-analysis-reports)」を参照してください。最小重要度を指定するには、`Severity` プロパティを使用します。脆弱性の最大数を指定するには、`Number` プロパティを使用します。対応する UI: 出力タブ/レポート/成功基準/**[検出結果]** ## Reports (*action-name*/Outputs/**Reports** ) (オプション) テストレポートの設定を指定するセクション。対応する UI: [出力] タブ/**[レポート]** ## report-name-1 (*action-name*/Outputs/Reports/**report-name-1**) ([Reports](#test.configuration.reports) が含まれている場合は必須) 未加工レポートから生成される CodeCatalyst レポートに付ける名前。対応する UI: [出力] タブ/[レポート]/[レポートを手動で設定]/**[レポート名]** ## Format (*action-name*/Outputs/Reports/*report-name-1*/**Format**) ([Reports](#test.configuration.reports) が含まれている場合は必須) レポートに使用するファイル形式を指定します。指定できる値は以下のとおりです。 + テストレポートの場合: + Cucumber JSON には、**[Cucumber ]** (ビジュアルエディタ) または [`CUCUMBERJSON`] (YAML エディタ) を指定します。 + JUnit XML の場合は、**[JUnit]** (ビジュアルエディタ) または [`JUNITXML`] (YAML エディタ) を指定します。 + NUnit XML の場合は、**[NUnit]** (ビジュアルエディタ) または [`NUNITXML`] (YAML エディタ) を指定します。 + NUnit 3 XML の場合は、**[NUnit3]** (ビジュアルエディタ) または [`NUNIT3XML`] (YAML エディタ) を指定します。 + Visual Studio TRX の場合は、**[Visual Studio TRX]** (ビジュアルエディタ) または [`VISUALSTUDIOTRX`] (YAML エディタ) を指定します。 + TestNG XML の場合は、**[TestNG]** (ビジュアルエディタ) または [`TESTNGXML`] (YAML エディタ) を指定します。 + コードカバレッジレポートの場合: + Clover XML の場合は、**[Clover]** (ビジュアルエディタ) または [`CLOVERXML`] (YAML エディタ) を指定します。 + Cobertura XML の場合は、**[Cobertura]** (ビジュアルエディタ) または [`COBERTURAXML`] (YAML エディタ) を指定します。 + JaCoCo XML の場合は、**[JaCoCo]** (ビジュアルエディタ) または [`JACOCOXML`] (YAML エディタ) を指定します。 + [[simplecov-json]](https://github.com/simplecov-ruby/simplecov) ではなく [[simplecov]](https://github.com/vicentllongo/simplecov-json) によって生成された SimpleCov JSON の場合は、**[Simplecov]** (ビジュアルエディタ) または [`SIMPLECOV`] (YAML エディタ) を指定します。 + ソフトウェアコンポジション分析 (SCA) レポートの場合: + SARIF には、**[SARIF]** (ビジュアルエディタ) または [`SARIFSCA`] (YAML エディタ) を指定します。対応する UI: [出力] タブ/[レポート]/[レポートを手動で設定]/[レポートを追加]/[設定]/*report-name-1*/**[レポートタイプ]** と **[レポート形式]** ## Configuration (*action-name*/**Configuration**) (必須) アクションの設定プロパティを定義できるセクション。対応する UI: **[設定]** タブ ## Container (*action-name*/Configuration/**Container**) (オプション) アクションが処理を完了するために使用する Docker イメージまたは *[コンテナ]* を指定します。CodeCatalyst に付属する [[アクティブなイメージ]](build-images.md#build-curated-images) のいずれかを指定するか、独自のイメージを使用できます。独自のイメージを使用する場合は、Amazon ECR、Docker Hub、または別のレジストリに存在できます。Docker イメージを指定しない場合、アクションはその処理にアクティブなイメージの 1 つを使用します。デフォルトではどのアクティブなイメージが使用されているかについては、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。独自の Docker イメージの指定の詳細については、「[カスタムランタイム環境の Docker イメージをアクションに割り当てる](build-images.md#build-images-specify)」を参照してください。対応する UI: **ランタイム環境 Docker イメージ - オプション** ## Registry (*action-name*/Configuration/Container/**Registry**) (`Container` が含まれている場合は必須) イメージが保存されているレジストリを指定します。有効な値を次に示します。 + `CODECATALYST` (YAML エディタ) イメージは CodeCatalyst レジストリに保存されます。 + **[Docker Hub]** (ビジュアルエディタ) または [`DockerHub`] (YAML エディタ) イメージは Docker Hub イメージレジストリに保存されます。 + **[その他のレジストリ]** (ビジュアルエディタ) または [`Other`] (YAML エディタ) イメージはカスタムイメージレジストリに保存されます。公開されているレジストリを使用できます。 + **[Amazon Elastic Container Registry]** (ビジュアルエディタ) または [`ECR`] (YAML エディタ) イメージは Amazon Elastic Container Registry イメージリポジトリに保存されます。Amazon ECR リポジトリでイメージを使用するには、このアクションで Amazon ECR にアクセスする必要があります。このアクセスを有効にするには、次のアクセス許可とカスタム信頼ポリシーを含む [[IAM ロール]](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) を作成する必要があります。(既存のロールを変更して、必要に応じてアクセス許可とポリシーを含めることができます。) IAM ロールのロールポリシーには、次のアクセス許可を含める必要があります。 + `ecr:BatchCheckLayerAvailability` + `ecr:BatchGetImage` + `ecr:GetAuthorizationToken` + `ecr:GetDownloadUrlForLayer` IAM ロールには、次のカスタム信頼ポリシーを含める必要があります。 IAM ロールの作成に関する詳細については、「*IAM ユーザーガイド*」の「[ロールの作成とポリシーのアタッチ (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)」を参照してください。ロールを作成したら、環境を介してアクションに割り当てる必要があります。詳細については、「[環境とアクションの関連付け](deploy-environments-add-app-to-environment.md)」を参照してください。対応する UI: **[Amazon Elastic Container Registry]**、**[Docker Hub]**、**[その他のレジストリ]** オプション ## Image (*action-name*/Configuration/Container/**Image**) (`Container` が含まれている場合は必須) 次のいずれかを指定します。 + `CODECATALYST` レジストリを使用している場合は、イメージを次のいずれかの [[アクティブなイメージ]](build-images.md#build-curated-images) に設定します。 + `CodeCatalystLinux_x86_64:2024_03` + `CodeCatalystLinux_x86_64:2022_11` + `CodeCatalystLinux_Arm64:2024_03` + `CodeCatalystLinux_Arm64:2022_11` + `CodeCatalystLinuxLambda_x86_64:2024_03` + `CodeCatalystLinuxLambda_x86_64:2022_11` + `CodeCatalystLinuxLambda_Arm64:2024_03` + `CodeCatalystLinuxLambda_Arm64:2022_11` + `CodeCatalystWindows_x86_64:2022_11` + Docker Hub レジストリを使用している場合は、イメージを Docker Hub イメージ名とオプションのタグに設定します。例: `postgres:latest` + Amazon ECR レジストリを使用している場合は、イメージを Amazon ECR レジストリ URI に設定します。例: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo` + カスタムレジストリを使用している場合は、イメージをカスタムレジストリで期待される値に設定します。対応する UI: **[ランタイム環境の Docker イメージ]** (レジストリが `CODECATALYST` の場合)、**[Docker Hub イメージ]** (レジストリが **[Docker Hub]** の場合)、**[ECR イメージ URL]** (レジストリが **[Amazon Elastic Container Registry]** の場合)、および **[イメージ URL]** (レジストリが**[その他のレジストリ]** の場合)。 ## Steps (*action-name*/Configuration/**Steps**) (必須) ビルドツールをインストール、設定、実行するアクション中に実行するシェルコマンドを指定します。 npm プロジェクトをビルドする方法の例を次に示します。 ``` Steps: - Run: npm install - Run: npm run build ``` ファイルパスを指定する方法の例を次に示します。 ``` Steps: - Run: cd $ACTION_BUILD_SOURCE_PATH_WorkflowSource/app && cat file2.txt - Run: cd $ACTION_BUILD_SOURCE_PATH_MyBuildArtifact/build-output/ && cat file.txt ``` 出力ファイル名とパスの詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」と「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。対応する UI: [設定] タブ/**[シェルコマンド]** ## Packages (*action-name*/Configuration/**Packages**) (オプション) アクションが依存関係を解決するために使用するパッケージリポジトリを指定できるセクション。パッケージを使用すると、アプリケーション開発に使用されるソフトウェアパッケージを安全に保存および共有できます。パッケージの詳細については、「[CodeCatalyst でソフトウェアパッケージを公開および共有する](packages.md)」を参照してください。対応する UI: [設定] タブ/**[パッケージ]** ## NpmConfiguration (*action-name*/Configuration/Packages/**NpmConfiguration**) ([Packages](#build.configuration.packages) が含まれている場合は必須) npm パッケージ形式の設定を定義するセクション。この設定は、ワークフローの実行中にアクションによって使用されます。 npm パッケージ設定の詳細については、「[npmを使う](packages-npm.md)」を参照してください。対応する UI: [設定] タブ/[パッケージ]/[設定の追加]/**[npm]** ## PackageRegistries (*action-name*/Configuration/Packages/NpmConfiguration/**PackageRegistries**) ([Packages](#build.configuration.packages) が含まれている場合は必須) 一連のパッケージリポジトリの設定プロパティを定義できるセクション。対応する UI: [設定] タブ/[パッケージ]/[設定の追加]/[npm]/**[パッケージリポジトリの追加]** ## PackagesRepository (*action-name*/Configuration/Packages/NpmConfiguration/PackageRegistries/**PackagesRepository**) ([Packages](#build.configuration.packages) が含まれている場合は必須) アクションで使用する CodeCatalyst *[パッケージリポジトリ]* の名前を指定します。複数のデフォルトリポジトリを指定すると、最後のリポジトリが優先されます。パッケージリポジトリの作成方法については、「[パッケージリポジトリ](packages-concepts.md#packages-concepts-repository)」を参照してください。対応する UI: [設定] タブ/[パッケージ]/[設定の追加]/[npm]/[パッケージリポジトリの追加]/**[パッケージリポジトリ]** ## Scopes (*action-name*/Configuration/Packages/NpmConfiguration/PackageRegistries/**Scopes**) (オプション) パッケージレジストリで定義する *[スコープ]* のシーケンスを指定します。スコープを定義する場合、指定されたパッケージリポジトリは、一覧表示されているすべてのスコープのレジストリとして設定されます。スコープを持つパッケージが npm クライアントを介してリクエストされた場合、デフォルトの代わりにそのリポジトリが使用されます。各スコープ名には、「@」というプレフィックスを付ける必要があります。上書きスコープを含めると、最後のリポジトリが優先されます。 `Scopes` を省略すると、指定されたパッケージリポジトリは、アクションで使用されるすべてのパッケージのデフォルトレジストリとして構成されます。スコープの詳細については、「[パッケージの名前空間](packages-concepts.md#packages-concepts-package-namespaces)」および「[スコープパッケージ](https://docs.npmjs.com/cli/v10/using-npm/scope)」を参照してください。対応する UI: [設定] タブ/[パッケージ]/[設定の追加]/[npm]/[パッケージリポジトリを追加]/**[スコープ - オプション]** ## ExportAuthorizationToken (*action-name*/Configuration/Packages/**ExportAuthorizationToken**) (オプション) エクスポート認証トークン機能を有効または無効にします。有効にすると、エクスポートされた認証トークンを使用して、CodeCatalyst パッケージリポジトリで認証するようにパッケージマネージャーを手動で設定できます。トークンは、アクションで参照できる環境変数として使用できます。有効な値は `true` または `false` です。 `ExportAuthorizationToken` を省略した場合、デフォルトは `false` です。エクスポート認証トークンの詳細については、「[ワークフローアクションでの認証トークンの使用](workflows-package-export-token.md)」を参照してください。対応する UI: [設定] タブ/[パッケージ]/**[エクスポート認証トークン]** # ワークフローを使用したテスト CodeCatalyst では、ビルドやテストなど、さまざまなワークフローアクションの一環としてテストを実行できます。これらのすべてのワークフローアクションでは、品質レポートを生成できます。*テストアクション*は、テスト、コードカバレッジ、ソフトウェア構成分析、静的分析の各レポートを生成するワークフローアクションです。これらのレポートは CodeCatalyst コンソールに表示されます。 **Topics** + [ ## 品質レポートのタイプ ](#test-reporting) + [ # テストアクションの追加 ](test-add-action.md) + [ # テストアクションの結果の表示 ](test-view-results.md) + [ # アクション内で失敗したテストのスキップ ](test.error-handling.md) + [ # universal-test-runner との統合 ](test.universal-test-runner.md) + [ # アクションにおける品質レポートの設定 ](test-config-action.md) + [ # テストのベストプラクティス ](test-best-practices.md) + [ # サポートされている SARIF プロパティ ](test.sarif.md) ## 品質レポートのタイプ Amazon CodeCatalyst テストアクションでは、次のタイプの品質レポートがサポートされています。これらのレポートを YAML 形式で設定する方法の例については、「[品質レポートの YAML 例](test-config-action.md#test.success-criteria-example)」を参照してください。 **Topics** + [ ### テストレポート ](#test-reports) + [ ### コードカバレッジレポート ](#test-code-coverage-reports) + [ ### ソフトウェア構成分析レポート ](#test-sca-reports) + [ ### 静的分析レポート ](#test-static-analysis-reports) ### テストレポート CodeCatalyst では、ユニットテスト、統合テスト、システムテストを設定し、ビルド中に実行できます。その後、CodeCatalyst でそのテストの結果を含むレポートを作成できます。テストレポートは、テストに関する問題のトラブルシューティングに役立ちます。複数のビルドで生成されたテストレポートが多数ある場合、テストレポートを使用して失敗率を確認し、ビルドを最適化できます。以下のテストレポートファイル形式を使用できます。 + Cucumber JSON (.json) + JUnit XML (.xml) + NUnit XML (.xml) + NUnit3 XML (.xml) + TestNG XML (.xml) + Visual Studio TRX (.trx、.xml) ### コードカバレッジレポート CodeCatalyst で、テストのコードカバレッジレポートを生成できます。CodeCatalyst では、次のコードカバレッジメトリクスが提供されます。 [ラインカバレッジ] テストでカバーされるステートメントの数を測定します。ステートメントは、コメントを含まない単一の命令です。 `line coverage = (total lines covered)/(total number of lines)` [ブランチカバレッジ] コントロール構造のすべてのブランチのうち、テストでカバーされるブランチの数を測定します (`if` または `case` ステートメントなど)。 `branch coverage = (total branches covered)/(total number of branches)` 以下のコードカバレッジレポートファイル形式がサポートされています。 + JaCoCo XML (.xml) + SimpleCov JSON ([simplecov](https://github.com/simplecov-ruby/simplecov) によって生成された .json であり、[simplecov-json](https://github.com/vicentllongo/simplecov-json) ではありません) + Clover XML (バージョン 3、.xml) + Cobertura XML (.xml) + LCOV (.info) ### ソフトウェア構成分析レポート CodeCatalyst では、ソフトウェア構成分析 (SCA) ツールを使用してアプリケーションのコンポーネントを分析し、既知のセキュリティ脆弱性を確認できます。重要度や修正方法がさまざまに異なる脆弱性を詳細に説明する SARIF レポートを検出して解析できます。有効な重要度の値は、重要度が高い順に、`CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。以下の SCA レポートファイル形式がサポートされています。 + SARIF (.sarif、.json) ### 静的分析レポート静的分析 (SA) レポートを使用して、ソースレベルのコード欠陥を特定できます。CodeCatalyst では、SA レポートを生成して、デプロイする前にコードの問題を解決できます。これらの問題には、バグ、セキュリティの脆弱性、品質の問題、およびその他の脆弱性が含まれます。有効な重要度の値は、重要度が高い順に、`CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。 CodeCatalyst では、次の SA メトリクスが提供されます。バグソースコードで検出される可能性のあるバグの数を識別します。これらのバグには、メモリの安全性に関する問題が含まれることがあります。バグの例を次に示します。 ``` // The while loop will inadvertently index into array x out-of-bounds int x[64]; while (int n = 0; n <= 64; n++) { x[n] = 0; } ``` セキュリティの脆弱性ソースコードで検出される可能性のあるセキュリティ脆弱性を特定します。これらのセキュリティ脆弱性には、シークレットトークンをプレーンテキストで保存するなどの問題が含まれることがあります。品質に関する問題ソースコードで検出される可能性のある品質問題を特定します。これらの品質問題には、スタイルの規則に関する問題が含まれることがあります。品質問題の例を次に示します。 ``` // The function name doesn't adhere to the style convention of camelCase int SUBTRACT(int x, int y) { return x-y } ``` その他の脆弱性ソースコードで検出される可能性のあるその他の脆弱性を特定します。 CodeCatalyst では、以下の SA レポートファイル形式がサポートされています。 + PyLint (.py) + ESLint (.js、.jsx、.ts、.tsx) + SARIF (.sarif、.json) # テストアクションの追加 CodeCatalyst ワークフローにテストアクションを追加するには、次の手順に従います。 ------ #### [ Visual ] **ビジュアルエディタを使用してテストアクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. **[アクション]** を選択します。 1. **[アクション]** で **[テスト]** を選択します。 1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[ビルドおよびテストアクション YAML](build-action-ref.md)」を参照してください。このリファレンスでは、YAML エディタとビジュアルエディタの両方に表示される各フィールド (および対応する YAML プロパティ値) に関する詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用してビルドアクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. **[アクション]** を選択します。 1. **[アクション]** で **[テスト]** を選択します。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[ビルドおよびテストアクション YAML](build-action-ref.md)」に記載されています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ ## テストアクションの定義テストアクションは、ワークフロー定義ファイル内の一連の YAML プロパティとして定義されます。これらのプロパティの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」の「[ビルドおよびテストアクション YAML](build-action-ref.md)」を参照してください。 # テストアクションの結果の表示生成されたログ、レポート、変数など、テストアクションの結果を表示するには、以下の手順に従います。 **テストアクションの結果を表示するには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. ワークフロー図で、テストアクションの名前を選択します。例えば、**[テスト]** です。 1. アクションによって生成されたログを表示するには、**[ログ]** を選択します。さまざまなアクションフェーズのログが表示されます。必要に応じてログを展開または折りたたむことができます。 1. テストアクションによって生成されたテストレポートを表示するには、**[レポート]** を選択するか、ナビゲーションペインで **[レポート]** を選択します。詳細については、「[品質レポートのタイプ](test-workflow-actions.md#test-reporting)」を参照してください。 1. テストアクションに使用する設定を表示するには、**[設定]** タブを選択します。詳細については、「[テストアクションの追加](test-add-action.md)」を参照してください。 1. テストアクションで使用される変数を表示するには、**[変数]** を選択します。詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 # アクション内で失敗したテストのスキップアクションに複数のテストコマンドがある場合、前のコマンドが失敗しても後続のテストコマンドを実行可能にする必要が生じることがあります。例えば、以下のコマンドでは、`test1` が失敗した場合でも、常に `test2` を実行可能にすることが望ましいです。 ``` Steps: - Run: npm install - Run: npm run test1 - Run: npm run test2 ``` 通常、あるステップがエラーを返すと、Amazon CodeCatalyst はワークフローアクションを停止し、失敗としてマークします。エラー出力を `null` にリダイレクトすることで、アクションステップの実行を継続できます。これは、コマンドに `2>/dev/null` を追加することで実行できます。前の例にこの変更を加えると、次のようになります。 ``` Steps: - Run: npm install - Run: npm run test1 2>/dev/null - Run: npm run test2 ``` 2 番目のコードスニペットでは、`npm install` コマンドのステータスが適用され、`npm run test1` コマンドで返されるエラーは無視されます。その結果、`npm run test2` コマンドが実行されます。これにより、エラーが発生したかどうかにかかわらず、両方のレポートを一度に表示できるようになります。 # universal-test-runner との統合テストアクションは、オープンソースのコマンドラインツール `universal-test-runner` と統合されます。`universal-test-runner` は[テスト実行プロトコル](https://github.com/aws/universal-test-runner/blob/main/protocol/README.md)を使用して、特定のフレームワーク内の任意の言語のテストを実行します。`universal-test-runner` は、次のフレームワークをサポートしています。 + [Gradle](https://gradle.org/) + [Jest](https://jestjs.io/) + [Maven](https://maven.apache.org/) + [pytest](https://pytest.org) + [.NET](https://learn.microsoft.com/en-us/dotnet/core/tools/) `universal-test-runner` は、テストアクション用にキュレートされたイメージにのみインストールされます。カスタムの Docker Hub または Amazon ECR を使用するようにテストアクションを設定する場合、`universal-test-runner` を手動でインストールして高度なテスト機能を有効にする必要があります。これを行うには、Node.js (14 以降) をイメージにインストールし、シェルコマンド `- Run: npm install -g @aws/universal-test-runner` を使用して `npm` で `universal-test-runner` をインストールします。シェルコマンドを使用してコンテナに Node.js をインストールする方法の詳細については、[Node Version Manager のインストールと更新](https://github.com/nvm-sh/nvm#install--update-script)に関する記事を参照してください。 `universal-test-runner` の詳細については、「[What is universal-test-runner?](https://github.com/aws/universal-test-runner#-what-is-universal-test-runner)」を参照してください。 ------ #### [ Visual ] **ビジュアルエディタで universal-test-runner を使用するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. **[アクション]** を選択します。 1. **[アクション]** で **[テスト]** を選択します。 1. **[設定]** タブで、サポートされているフレームワークを選択してサンプルコードを更新し、**[シェルコマンド]** フィールドを完成させます。例えば、サポートされているフレームワークを使用するには、次のような `Run` コマンドを使用します。 ``` - Run: run-tests ``` 必要なフレームワークがサポートされていない場合は、カスタムアダプターまたはカスタムランナーを作成して提供することを検討してください。**[シェルコマンド]** フィールドの説明については、「[Steps](build-action-ref.md#build.configuration.steps)」を参照してください。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタで universal-test-runner を使用するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. **[アクション]** を選択します。 1. **[アクション]** で **[テスト]** を選択します。 1. 必要に応じて YAML コードを変更します。例えば、サポートされているフレームワークを使用するには、次のような `Run` コマンドを使用します。 ``` Configuration: Steps: - Run: run-tests ``` 必要なフレームワークがサポートされていない場合は、カスタムアダプターまたはカスタムランナーを作成して提供することを検討してください。**Steps** プロパティの説明については、「[Steps](build-action-ref.md#build.configuration.steps)」を参照してください。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # アクションにおける品質レポートの設定このセクションでは、アクションで品質レポートを設定する方法について説明します。 **Topics** + [ ## 自動検出によるレポートと手動設定によるレポート ](#test.auto-discovery) + [ ## レポートの成功基準の設定 ](#test.success-criteria) + [ ## 品質レポートの YAML 例 ](#test.success-criteria-example) ## 自動検出によるレポートと手動設定によるレポート自動検出を有効にすると、CodeCatalyst では、アクションに渡されたすべての入力と、アクション自体によって生成されたすべてのファイルが検索され、テストレポート、コードカバレッジレポート、ソフトウェア構成分析 (SCA) レポート、静的分析 (SA) レポートが検出されます。これらのレポートを CodeCatalyst で個別に表示して操作できます。どのレポートを生成するかを手動で設定することもできます。生成するレポートのタイプとファイル形式を指定できます。詳細については、「[品質レポートのタイプ](test-workflow-actions.md#test-reporting)」を参照してください。 ## レポートの成功基準の設定テストレポート、コードカバレッジレポート、ソフトウェア構成分析 (SCA) レポート、または静的分析 (SA) レポートの成功基準を決定する値を設定できます。成功基準は、レポートが合格か不合格かを決定するしきい値です。CodeCatalyst では、テスト、コードカバレッジ、SCA、または SA のいずれかのレポートが最初に生成され、その後、生成されたレポートに成功基準が適用されます。次に、成功基準が満たされたか、およびどの程度満たされたかが示されます。指定した成功基準がレポートで満たされていない場合、その成功基準が指定された CodeCatalyst アクションは失敗します。例えば、SCA レポートの成功基準を設定する場合、有効な脆弱性値は、重要度が高い順に、`CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。重要度が `HIGH` である脆弱性をスキャンするように基準を設定すると、重要度が `HIGH` である脆弱性が 1 つ以上存在する場合、または重要度が `HIGH` である脆弱性は存在しないものの、より重要度の高い脆弱性が 1 つ以上存在する場合 (例えば、重要度が `CRITICAL` である脆弱性が 1 つ存在するなど)、レポートが失敗します。成功基準を指定しない場合は、次のようになります。 + 未加工のレポートに基づいて生成された CodeCatalyst レポートには、成功基準は表示されません。 + 関連するワークフローアクションが合格または不合格かを決定するために成功基準が使用されることはありません。 ------ #### [ Visual ] **成功基準を設定するには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. レポートを生成するアクションを含むワークフローを選択します。このレポートに成功基準を適用します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、CodeCatalyst レポートを生成するように設定したアクションを選択します。 1. **[出力]** タブを選択します。 1. **[オートディスカバリーレポート]** または **[レポートを手動で設定]**で、**[成功基準]** を選択します。成功基準が表示されます。前の選択に基づいて、以下のオプションの一部またはすべてが表示されます。 **[パスレート]** 関連する CodeCatalyst レポートが合格としてマークされるために、テストレポート内のテストに求められる合格の割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。パスレートの基準は、テストレポートにのみ適用されます。テストレポートの詳細については、「[テストレポート](test-workflow-actions.md#test-reports)」を参照してください。 **[ラインカバレッジ]** 関連する CodeCatalyst レポートが合格としてマークされるために、コードカバレッジレポート内でカバーする必要がある行の割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。ラインカバレッジ基準は、コードカバレッジレポートにのみ適用されます。コードカバレッジレポートの詳細については、「[コードカバレッジレポート](test-workflow-actions.md#test-code-coverage-reports)」を参照してください。 **[ブランチカバレッジ]** 関連する CodeCatalyst レポートが合格としてマークされるために、コードカバレッジレポート内のブランチに求められるカバレッジの割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。ブランチカバレッジ基準は、コードカバレッジレポートにのみ適用されます。コードカバレッジレポートの詳細については、「[コードカバレッジレポート](test-workflow-actions.md#test-code-coverage-reports)」を参照してください。 **[脆弱性 (SCA)]** 関連する CodeCatalyst レポートが合格としてマークされるように、SCA レポート内で許容される脆弱性の最大数と重要度を指定します。脆弱性を指定するには、以下を指定する必要があります。 + カウントに含める脆弱性の最小重要度。有効な値は、重要度が高い順に `CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。例えば、`HIGH` を選択すると、`HIGH` と `CRITICAL` の脆弱性が集計されます。 + 指定された重要度の脆弱性の最大許容数。この数を超えると、CodeCatalyst レポートは不合格としてマークされます。有効な値は整数です。脆弱性の基準は SCA レポートにのみ適用されます。SCA レポートの詳細については、「[ソフトウェア構成分析レポート](test-workflow-actions.md#test-sca-reports)」を参照してください。 **[バグ]** 関連する CodeCatalyst レポートが合格としてマークされるように、SA レポート内で許容されるバグの最大数と重要度を指定します。バグを指定するには、以下を指定する必要があります。 + カウントするバグの最小重要度。有効な値は、重要度が高い順に、`CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。例えば、`HIGH` を選択すると、`HIGH` と `CRITICAL` のバグが集計されます。 + 指定された重要度のバグの最大許容数。この数を超えると、CodeCatalyst レポートは失敗としてマークされます。有効な値は整数です。バグ基準は、PyLint SA レポートおよび ESLint SA レポートにのみ適用されます。SA レポートの詳細については、「[静的分析レポート](test-workflow-actions.md#test-static-analysis-reports)」を参照してください。 **[セキュリティの脆弱性]** 関連する CodeCatalyst レポートが合格としてマークされるように、SA レポート内で許容されるセキュリティ脆弱性の最大数と重要度を指定します。セキュリティの脆弱性を指定するには、以下を指定する必要があります。 + カウントするセキュリティ脆弱性の最小重要度。有効な値は、重要度が高い順に、`CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。例えば、`HIGH` を選択すると、`HIGH` と `CRITICAL` のセキュリティ脆弱性が集計されます。 + 指定された重要度のセキュリティ脆弱性の最大許容数。この数を超えると、CodeCatalyst レポートは失敗としてマークされます。有効な値は整数です。セキュリティ脆弱性の基準は、PyLint SA レポートおよび ESLint SA レポートにのみ適用されます。SA レポートの詳細については、「[静的分析レポート](test-workflow-actions.md#test-static-analysis-reports)」を参照してください。 **[品質に関する問題]** 関連する CodeCatalyst レポートが合格としてマークされるように、SA レポート内で許容される品質問題の最大数と重要度を指定します。品質問題を指定するには、以下を指定する必要があります。 + カウントに含める品質問題の最小重要度。有効な値は、重要度が高い順に、`CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。例えば、`HIGH` を選択すると、`HIGH` と `CRITICAL` の品質問題が集計されます。 + 指定された重要度の品質問題の最大許容数。この数を超えると、CodeCatalyst レポートは失敗としてマークされます。有効な値は整数です。品質問題の基準は、PyLint SA レポートおよび ESLint SA レポートにのみ適用されます。SA レポートの詳細については、「[静的分析レポート](test-workflow-actions.md#test-static-analysis-reports)」を参照してください。 1. **[コミット]** を選択します。 1. ワークフローを実行して CodeCatalyst で未加工のレポートに成功基準を適用し、成功基準情報を含む関連する CodeCatalyst レポートを再生成します。詳細については、「[手動でのワークフロー実行の開始](workflows-manually-start.md)」を参照してください。 ------ #### [ YAML ] **成功基準を設定するには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. レポートを生成するアクションを含むワークフローを選択します。このレポートに成功基準を適用します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ワークフロー図で、CodeCatalyst レポートを生成するように設定したアクションを選択します。 1. [詳細] ペインで、**[出力]** タブを選択します。 1. アクション内の `AutoDiscoverReports` セクションまたは `Reports` セクションに、**SuccessCriteria** プロパティを追加し、`PassRate`、`LineCoverage`、`BranchCoverage`、`Vulnerabilities`、`StaticAnalysisBug`、`StaticAnalysisSecurity`、`StaticAnalysisQuality` の各プロパティを設定します。これらの各プロパティの説明については、「[ビルドおよびテストアクション YAML](build-action-ref.md)」を参照してください。 1. **[コミット]** を選択します。 1. ワークフローを実行して CodeCatalyst で未加工のレポートに成功基準を適用し、成功基準情報を含む関連する CodeCatalyst レポートを再生成します。ワークフローの開始に関する詳細については、「[手動でのワークフロー実行の開始](workflows-manually-start.md)」を参照してください。 ------ ## 品質レポートの YAML 例次の例は、テストレポート、コードカバレッジレポート、ソフトウェア構成分析レポート、静的分析レポートの 4 つのレポートを手動で設定する方法を示しています。 ``` Reports: MyTestReport: Format: JUNITXML IncludePaths: - "*.xml" ExcludePaths: - report1.xml SuccessCriteria: PassRate: 90 MyCoverageReport: Format: CLOVERXML IncludePaths: - output/coverage/jest/clover.xml SuccessCriteria: LineCoverage: 75 BranchCoverage: 75 MySCAReport: Format: SARIFSCA IncludePaths: - output/sca/reports.xml SuccessCriteria: Vulnerabilities: Number: 5 Severity: HIGH MySAReport: Format: ESLINTJSON IncludePaths: - output/static/eslint.xml SuccessCriteria: StaticAnalysisBug: Number: 10 Severity: MEDIUM StaticAnalysisSecurity: Number: 5 Severity: CRITICAL StaticAnalysisQuality: Number: 0 Severity: INFORMATIONAL ``` # テストのベストプラクティス CodeCatalyst で提供されるテスト機能を使用する際は、以下のベストプラクティスに従うことをお勧めします。 **Topics** + [ ## 自動検出 ](#test.best-auto-discovery) + [ ## 成功基準 ](#test.best-success-criteria) + [ ## パスの包含/除外 ](#test.best-include-exclude) ## 自動検出 CodeCatalyst でアクションを設定する際に、自動検出を使用すると、JUnit テストレポートなどのさまざまなツールの出力が自動的に検出され、その出力を元に関連する CodeCatalyst レポートが生成されます。自動検出を活用した場合、検出された出力の名前やパスが変更されても、レポートが引き続き生成されます。新しいファイルを追加すると、CodeCatalyst で自動的に検出され、関連するレポートが生成されます。ただし、自動検出を使用する場合は、この機能に関して以下の点を考慮することが重要です。 + アクション内で自動検出を有効にすると、同じタイプのすべての自動検出レポートで同じ成功基準が共有されます。例えば、最小のパスレートなどの共通の基準は、自動検出されるすべてのテストレポートに適用されます。同じタイプのレポートに異なる基準が必要な場合は、それらのレポートごとに明示的に設定する必要があります。 + 自動検出では、依存関係によって生成されたレポートも検出されます。成功基準が設定されている場合、それらのレポートに関するアクションが失敗する可能性があります。この問題は、エクスクルードパスの設定を更新することで解決できます。 + 自動検出では、実行時にアクションがスキャンされるため、毎回同じレポートのリストが生成されるとは限りません。常に特定のレポートが生成されるようにするには、レポートを明示的に設定する必要があります。例えば、ビルドの過程でテストの実行が停止した場合、テストフレームワークで出力は生成されず、その結果、テストレポートも生成されないため、アクションは成功する可能性があります。アクションの成功をその特定のテストに依存させる場合は、そのレポートを明示的に設定する必要があります。 **ヒント** 新規または既存のプロジェクトを開始する際は、プロジェクトディレクトリ全体 (`**/*` を含む) に対して自動検出を使用します。これにより、サブディレクトリ内のファイルを含め、プロジェクト内のすべてのファイルに対してレポート生成処理が呼び出されます。詳細については、「[アクションにおける品質レポートの設定](test-config-action.md)」を参照してください。 ## 成功基準成功基準を設定することで、レポートに品質しきい値を適用できます。例えば、2 つのコードカバレッジレポートが自動検出され、1 つは 80% のラインカバレッジで、もう 1 つは 60% のラインカバレッジである場合、次のオプションがあります。 + ラインカバレッジの自動検出の成功基準を 80% に設定します。これにより、1 つ目のレポートは合格し、2 つ目のレポートは失敗し、アクション全体としては失敗します。ワークフローのブロックを解除するには、2 つ目のレポートのラインカバレッジが 80% を超えるまで、プロジェクトに新しいテストを追加します。 + ラインカバレッジの自動検出の成功基準を 60% に設定します。これにより、両方のレポートが合格し、アクションは成功します。その後、2 つ目のレポートのコードカバレッジを向上させることができます。ただし、このアプローチでは、1 つ目のレポートのカバレッジが 80% 未満に低下しないことを保証できません。 + ビジュアルエディタを使用するか、レポートごとに明示的な YAML セクションとパスを追加することで、レポートの一方または両方を明示的に設定します。これにより、レポートごとに個別の成功基準とカスタム名を設定できます。ただし、このアプローチでは、レポートパスが変更されると、アクションが失敗する可能性があります。詳細については、「[レポートの成功基準の設定](test-config-action.md#test.success-criteria)」を参照してください。 ## パスの包含/除外アクション結果を確認する際は、`IncludePaths` と `ExcludePaths` を設定することで CodeCatalyst で生成されるレポートのリストを調整できます。 + `IncludePaths` を使用して、CodeCatalyst でレポートの検索時に含めるファイルとファイルパスを指定します。例えば、`"/test/report/*"` を指定すると、CodeCatalyst では `/test/report/` ディレクトリを検索するアクションで使用されるビルドイメージ全体が検索されます。そのディレクトリが見つかると、CodeCatalyst でそのディレクトリ内のレポートが検索されます。 **注記** 手動で設定するレポートの場合、`IncludePaths` は単一のファイルに一致する glob パターンである必要があります。 + `ExcludePaths` を使用して、CodeCatalyst でレポートの検索時に除外されるファイルとファイルパスを指定します。例えば、`"/test/reports/**/*"` を指定すると、CodeCatalyst で `/test/reports/` ディレクトリ内のファイルは検索されません。ディレクトリ内のすべてのファイルを無視するには、`**/*` glob パターンを使用します。考えられる glob パターンとしては、以下のようなものがあります。 | パターン | 説明 | | --- | --- | | `*.*` | 現在のディレクトリ内のドットを含むオブジェクト名すべてと一致する | | `*.xml` | 現在のディレクトリ内の `.xml` で終わるオブジェクト名すべてと一致する | | `*.{xml,txt}` | 現在のディレクトリ内の `.xml` または `.txt` で終わるオブジェクト名すべてと一致する | | `**/*.xml` | すべてのディレクトリ内の `.xml` で終わるオブジェクト名と一致する | | `testFolder` | `testFolder` というオブジェクトと一致し、ファイルとして扱う | | `testFolder/*` | `testFolder` の 1 階層下のサブフォルダ (`testFolder/file.xml` など) 内のオブジェクトと一致する | | `testFolder/*/*` | `testFolder` の 2 階層下のサブフォルダ (`testFolder/reportsFolder/file.xml` など) 内のオブジェクトと一致する | | `testFolder/**` | `testFolder` 内のサブフォルダ、および `testFolder` 以下にあるファイルと一致する (`testFolder/file.xml` や `testFolder/otherFolder/file.xml` など) | CodeCatalyst では、glob パターンを次のように解釈します。 + スラッシュ (`/`) 文字は、ファイルパス内のディレクトリを区切ります。 + アスタリスク (`*`) 記号は、フォルダの境界を超えない、0 文字以上の名前の要素と一致します。 + 二重アスタリスク (`**`) は、すべてのディレクトリをまたいで、0 文字以上の名前の要素と一致します。 **注記** `ExcludePaths` は `IncludePaths` よりも優先されます。`IncludePaths` と `ExcludePaths` の両方に同じフォルダが含まれている場合、そのフォルダはレポート生成のためにスキャンされません。 # サポートされている SARIF プロパティ Static Analysis Results Interchange Format (SARIF) は、Amazon CodeCatalyst のソフトウェア構成分析 (SCA) レポートおよび静的分析レポートで使用可能な出力ファイル形式です。次の例は、静的分析レポートで SARIF を手動で設定する方法を示しています。 ``` Reports: MySAReport: Format: SARIFSA IncludePaths: - output/sa_report.json SuccessCriteria: StaticAnalysisFinding: Number: 25 Severity: HIGH ``` CodeCatalyst では、次の SARIF プロパティがサポートされています。これらのプロパティを使用して、レポートにおける分析結果の表示を最適化できます。 **Topics** + [ ## `sarifLog` オブジェクト ](#test.sarif.sarifLog) + [ ## `run` オブジェクト ](#test.sarif.run) + [ ## `toolComponent` オブジェクト ](#test.sarif.toolComponent) + [ ## `reportingDescriptor` オブジェクト ](#test.sarif.reportingDescriptor) + [ ## `result` オブジェクト ](#test.sarif.result) + [ ## `location` オブジェクト ](#test.sarif.location) + [ ## `physicalLocation` オブジェクト ](#test.sarif.physicalLocation) + [ ## `logicalLocation` オブジェクト ](#test.sarif.logicalLocation) + [ ## `fix` オブジェクト ](#test.sarif.fix) ## `sarifLog` オブジェクト | 名前 | 必要 | 説明 | | --- | --- | --- | | `$schema` | はい | バージョン [2.1.0](https://json.schemastore.org/sarif-2.1.0.json) の SARIF JSON スキーマの URI です。 | | `version` | はい | CodeCatalyst は、SARIF バージョン 2.1.0 のみをサポートしています。 | | `runs[]` | はい | SARIF ファイルには 1 つまたは複数の実行で構成された配列が含まれており、それぞれが分析ツールの単一の実行を表します。 | ## `run` オブジェクト | 名前 | 必要 | 説明 | | --- | --- | --- | | `tool.driver` | はい | 分析ツールを説明する `toolComponent` オブジェクトです。 | | `tool.name` | いいえ | 分析の実行に使用されるツールの名前を示すプロパティです。 | | `results[]` | はい | CodeCatalyst に表示される分析ツールの結果です。 | ## `toolComponent` オブジェクト | 名前 | 必要 | 説明 | | --- | --- | --- | | `name` | はい | 分析ツールの名前です。 | | `properties.artifactScanned` | いいえ | 分析ツールで分析されたアーティファクトの合計数です。 | | `rules[]` | はい | ルールを表す `reportingDescriptor` オブジェクトの配列です。分析ツールでは、これらのルールに基づいて、分析されたコードの問題を検出します。 | ## `reportingDescriptor` オブジェクト | 名前 | 必要 | 説明 | | --- | --- | --- | | `id` | はい | 検出結果の参照に使用される、ルールの一意の識別子です。最大長: 1,024 文字 | | `name` | いいえ | ルールの表示名です。最大長: 1,024 文字 | | `shortDescription.text` | いいえ | ルールの短い説明です。最大長: 3,000 文字 | | `fullDescription.text` | いいえ | ルールの完全な説明です。最大長: 3,000 文字 | | `helpUri` | いいえ | ルールのプライマリドキュメントの絶対 URI を含むようにローカライズできる文字列です。最大長: 3,000 文字 | | `properties.unscore` | いいえ | スキャンの検出結果がスコアリングされているかを示すフラグです。 | | `properties.score.severity` | いいえ | 検出結果の重要度レベルを指定する固定された文字列セットです。最大長: 1,024 文字 | | `properties.cvssv3_baseSeverity` | いいえ | [Common Vulnerability Scoring System v3.1](https://www.first.org/cvss/v3.1/specification-document) に基づく重要度の定性評価です。 | | `properties.cvssv3_baseScore` | いいえ | CVSS v3 ベーススコアの範囲は [0.0～10.0](https://nvd.nist.gov/vuln-metrics/cvss) です。 | | `properties.cvssv2_severity` | いいえ | CVSS v3 値が存在しない場合、CodeCatalyst は CVSS v2 値を検索します。 | | `properties.cvssv2_score` | いいえ | CVSS v2 ベーススコアの範囲は [0.0～10.0](https://nvd.nist.gov/vuln-metrics/cvss) です。 | | `properties.severity` | いいえ | 検出結果の重要度レベルを指定する固定された文字列セットです。最大長: 1,024 文字 | | `defaultConfiguration.level` | いいえ | ルールのデフォルトの重要度です。 | ## `result` オブジェクト | 名前 | 必要 | 説明 | | --- | --- | --- | | `ruleId` | はい | 検出結果の参照に使用される、ルールの一意の識別子です。最大長: 1,024 文字 | | `ruleIndex` | はい | ツールコンポーネント `rules[]` 内で関連付けられたルールのインデックスです。 | | `message.text` | はい | 結果を説明するメッセージです。各検出結果に対してメッセージを表示します。最大長: 3,000 文字 | | `rank` | いいえ | 結果の優先度、すなわち重要度を 0.0～100.0 の範囲で表す値です。このスケール値では、0.0 が最低優先度、100.0 が最高優先度を示します。 | | `level` | いいえ | 結果の重要度です。最大長: 1,024 文字 | | `properties.unscore` | いいえ | スキャンの検出結果がスコアリングされているかを示すフラグです。 | | `properties.score.severity` | いいえ | 検出結果の重要度レベルを指定する固定された文字列セットです。最大長: 1,024 文字 | | `properties.cvssv3_baseSeverity` | いいえ | [Common Vulnerability Scoring System v3.1](https://www.first.org/cvss/v3.1/specification-document) に基づく重要度の定性評価です。 | | `properties.cvssv3_baseScore` | いいえ | CVSS v3 ベーススコアの範囲は [0.0～10.0](https://nvd.nist.gov/vuln-metrics/cvss) です。 | | `properties.cvssv2_severity` | いいえ | CVSS v3 値が存在しない場合、CodeCatalyst は CVSS v2 値を検索します。 | | `properties.cvssv2_score` | いいえ | CVSS v2 ベーススコアの範囲は [0.0～10.0](https://nvd.nist.gov/vuln-metrics/cvss) です。 | | `properties.severity` | いいえ | 検出結果の重要度レベルを指定する固定された文字列セットです。最大長: 1,024 文字 | | `locations[]` | はい | 結果が検出された場所のセットです。問題を修正するためにすべての指定された場所で変更が必要な場合を除き、1 つの場所のみを含めます。CodeCatalyst は、location 配列内の最初の値を使用して結果に注釈を付けます。 `location` オブジェクトの最大数: 10 | | `relatedLocations[]` | いいえ | 検出結果に関連する他の場所の参照リストです。 `location` オブジェクトの最大数: 50 | | `fixes[]` | いいえ | スキャンツールで提供される修正推奨を示す `fix` オブジェクトの配列です。CodeCatalyst は、`fixes` 配列内の最初の修正推奨を使用します。 | ## `location` オブジェクト | 名前 | 必要 | 説明 | | --- | --- | --- | | `physicalLocation` | はい | アーティファクトとリージョンを識別します。 | | `logicalLocations[]` | いいえ | アーティファクトを参照せずに名前で示される場所のセットです。 | ## `physicalLocation` オブジェクト | 名前 | 必要 | 説明 | | --- | --- | --- | | `artifactLocation.uri` | はい | アーティファクトの場所を示す URI です。通常は、リポジトリ内に存在するファイルまたはビルド中に生成されるファイルを指します。 | | `fileLocation.uri` | いいえ | ファイルの場所を示すフォールバック URI です。これは、`artifactLocation.uri` が空を返す場合に使用されます。 | | `region.startLine` | はい | そのリージョン内で最初に文字が存在する行番号です。 | | `region.startColumn` | はい | そのリージョン内で最初に文字が存在する列番号です。 | | `region.endLine` | はい | そのリージョン内で最後に文字が存在する行番号です。 | | `region.endColumn` | はい | そのリージョン内で最後に文字が存在する列番号です。 | ## `logicalLocation` オブジェクト | 名前 | 必要 | 説明 | | --- | --- | --- | | `fullyQualifiedName` | いいえ | 結果の場所を示す追加情報です。最大長: 1,024 文字 | ## `fix` オブジェクト | 名前 | 必要 | 説明 | | --- | --- | --- | | `description.text` | いいえ | 各検出結果に対する修正推奨を表示するメッセージです。最大長: 3,000 文字 | | `artifactChanges.[0].artifactLocation.uri` | いいえ | 更新する必要があるアーティファクトの場所を示す URI です。 | # ワークフローを使用したデプロイ [CodeCatalyst ワークフロー](workflow.md)を使用すると、Amazon ECS などのさまざまなターゲットにアプリケーションやその他のリソースをデプロイできます AWS Lambda。 ## アプリケーションをデプロイする方法を教えてください。 CodeCatalyst を使用してアプリケーションまたはリソースをデプロイするには、まずワークフローを作成し、その中にデプロイアクションを指定します。*[デプロイアクション]* は、デプロイする*内容*、デプロイする*場所*、デプロイ*方法* (ブルー/グリーンスキームを使用するなど) を定義するワークフロービルドブロックです。CodeCatalyst コンソールのビジュアルエディタ、または YAML エディタを使用して、ワークフローにデプロイアクションを追加します。アプリケーションまたはリソースをデプロイするための大まかなステップは次のとおりです。 **アプリケーションをビルドするには (概要レベルのタスク)** 1. CodeCatalyst プロジェクトで、デプロイするアプリケーションの **[ソースコードを追加]** します。詳細については、「[CodeCatalyst のプロジェクト用リポジトリにソースコードを保存する](source-repositories.md)」を参照してください。 1. CodeCatalyst プロジェクトで、デプロイ先のターゲット AWS アカウントとオプションの Amazon Virtual Private Cloud (VPC) を定義する**環境を追加します**。詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」を参照してください。 1. CodeCatalyst プロジェクトで、**[ワークフローを作成]** します。ワークフローでは、アプリケーションをビルド、テスト、デプロイする方法を定義します。詳細については、「[初めてのワークフロー](workflows-getting-started.md)」を参照してください。 1. ワークフローでは、**[トリガーを追加]**、**[ビルドアクション]**、および任意で **[テストアクション]** を追加します。詳細については[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)、[ビルドアクションの追加](build-add-action.md)、および[テストアクションの追加](test-add-action.md)を参照してください。 1. ワークフローで、**[デプロイアクションを追加]** します。CodeCatalyst が提供する複数のデプロイアクションから、Amazon ECS などの異なるターゲットにアプリケーションをデプロイするアクションを選択できます。(ビルドアクションまたは GitHub アクションを使用してアプリケーションをデプロイすることもできます。ビルドアクションと GitHub アクションの詳細については、「[アクションをデプロイする他の方法](#deploy-concepts-alternatives)」を参照してください。) 1. **ワークフローの開始**は、手動で行うか、トリガーを介して自動で行います。ワークフローは、デプロイアクションを順番に実行して、アプリケーションとリソースをターゲットにビルド、テスト、デプロイします。詳細については、「[手動でのワークフロー実行の開始](workflows-manually-start.md)」を参照してください。 ## デプロイアクションの一覧次のデプロイアクションを使用できます。 + CloudFormation スタックをデプロイする – このアクションは、[AWS Serverless Application Model](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)指定した[CloudFormation テンプレート](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html) AWS に基づいてに CloudFormation スタックを作成します。詳細については、「[CloudFormation スタックのデプロイ](deploy-action-cfn.md)」を参照してください。 + Amazon ECS にデプロイ – このアクションは、指定した [[タスク定義]](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) ファイルを登録します。詳細については、「[ワークフローを使用した Amazon ECS へのデプロイ](deploy-action-ecs.md)」を参照してください。 + Kubernetes クラスターにデプロイ – このアクションは、アプリケーションを Amazon Elastic Kubernetes Service クラスターにデプロイします。詳細については、「[ワークフローを使用して Amazon EKS にデプロイする](deploy-action-eks.md)」を参照してください。 + AWS CDK deploy – このアクションは、[AWS CDK アプリケーションを](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_concepts) にデプロイします AWS。詳細については、「[ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)」を参照してください。 **注記** リソースをデプロイできる他の CodeCatalyst アクションもありますが、*[デプロイ]* 情報は **[環境]** ページに表示されないため、デプロイアクションとはみなされません。**[環境]** ページとデプロイの表示の詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」および「[デプロイ情報の表示](deploy-view-deployment-info.md)」を参照してください。 ## デプロイアクションの利点ワークフロー内でデプロイアクションを使用すると、次の利点があります。 + **デプロイ履歴** – デプロイの履歴を表示して、デプロイされたソフトウェアの変更を管理および伝達できます。 + **トレーサビリティ** – CodeCatalyst コンソールを使用してデプロイのステータスをトラッキングし、各アプリケーションリビジョンがいつ、どこでデプロイされたかを確認できます。 + **ロールバック** – エラーが発生した場合は、デプロイを自動的にロールバックします。デプロイのロールバックをアクティブ化するようにアラームを設定することもできます。 + **モニタリング** – ワークフローのさまざまな段階の進行状況を監視できます。 + **他の CodeCatalyst 機能との統合** – ソースコードを保存し、それを 1 つのアプリケーションからビルド、テスト、デプロイできます。 ## アクションをデプロイする他の方法デプロイアクションを使用する必要はないものの、前のセクションで説明した利点があるため、使用することを推奨します。代わりに、次の [[CodeCatalyst アクション]](workflows-actions.md#workflows-actions-types-cc) を使用できます。 + **[ビルド]** アクション。通常、対応するデプロイアクションが存在しないターゲットにデプロイする場合、またはデプロイ手順をより詳細に制御する場合は、ビルドアクションを使用します。ビルドアクションを使用してリソースをデプロイする方法については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。 + **[GitHub アクション]**。 CodeCatalyst ワークフロー内で [[GitHub アクション]](workflows-actions.md#workflows-actions-types-github) を使用して、アプリケーションとリソースを (CodeCatalyst アクションの代わりに) デプロイできます。CodeCatalyst ワークフロー内で GitHub アクションを使用する方法については、「[GitHub Actions との統合](integrations-github-actions.md)」を参照してください。 CodeCatalyst ワークフローを使用しない場合は、次の AWS サービスを使用してアプリケーションをデプロイすることもできます。 + AWS CodeDeploy – [CodeDeploy とは」を参照してください。](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) + AWS CodeBuild および AWS CodePipeline – [「とは」を参照してください AWS CodeBuild。](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) と [とは AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) + CloudFormation – [「とは」を参照してください CloudFormation。](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 複雑なエンタープライズデプロイには、CodeDeploy、CodeBuild、CodePipeline、および CloudFormation のサービスを使用します。 **Topics** + [ ## アプリケーションをデプロイする方法を教えてください。 ](#deploy-concepts) + [ ## デプロイアクションの一覧 ](#deploy-concepts-action-supported) + [ ## デプロイアクションの利点 ](#deploy-concepts-why-use) + [ ## アクションをデプロイする他の方法 ](#deploy-concepts-alternatives) + [ # ワークフローを使用した Amazon ECS へのデプロイ ](deploy-action-ecs.md) + [ # ワークフローを使用して Amazon EKS にデプロイする ](deploy-action-eks.md) + [ # CloudFormation スタックのデプロイ ](deploy-action-cfn.md) + [ # ワークフローを使用した AWS CDK アプリケーションのデプロイ ](cdk-dep-action.md) + [ # ワークフローを使用して AWS CDK アプリをブートストラップする ](cdk-boot-action.md) + [ # ワークフローを使用して Amazon S3 にファイルを発行する ](s3-pub-action.md) + [ # AWS アカウントと VPCs へのデプロイ ](deploy-environments.md) + [ # ワークフロー図でのアプリケーション URL の表示 ](deploy-app-url.md) + [ # デプロイターゲットの削除 ](deploy-remove-target.md) + [ # コミット別のデプロイステータスの追跡 ](track-changes.md) + [ # デプロイログの表示 ](deploy-deployment-logs.md) + [ # デプロイ情報の表示 ](deploy-view-deployment-info.md) # ワークフローを使用した Amazon ECS へのデプロイこのセクションでは、CodeCatalyst ワークフローを使用してコンテナ化されたアプリケーションを Amazon Elastic Container Service クラスターにデプロイする方法について説明します。これを行うには、**[Amazon ECS にデプロイ]** アクションをワークフローに追加する必要があります。このアクションは、指定した [[タスク定義]](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) ファイルを登録します。登録すると、タスク定義は [[Amazon ECS クラスター]](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-clusters) で実行されている [[Amazon ECS サービス]](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html) によってインスタンス化されます。「タスク定義の実装」は、アプリケーションを Amazon ECS にデプロイするのと同等です。このアクションを使用するには、Amazon ECS クラスター、サービス、タスク定義ファイルを準備しておく必要があります。 Amazon ECS の詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」を参照してください。 **ヒント** **[Amazon ECS にデプロイ]** アクションを使用する方法を示すチュートリアルについては、「[チュートリアル: Amazon ECS にアプリケーションをデプロイする](deploy-tut-ecs.md)」を参照してください。 **ヒント** **[Amazon ECS にデプロイ]** アクションの実用的な例については、**Node.js API with AWS Fargate** または Java **API with AWS Fargate** ブループリントを使用してプロジェクトを作成します。詳細については、「[ブループリントを使用したプロジェクトの作成](projects-create.md#projects-create-console-template)」を参照してください。 **Topics** + [ ## 「Amazon ECS にデプロイ」アクションで使用されるランタイムイメージ ](#deploy-action-ecs-runtime) + [ # チュートリアル: Amazon ECS にアプリケーションをデプロイする ](deploy-tut-ecs.md) + [ # 「Amazon ECS にデプロイ」アクションの追加 ](deploy-action-ecs-adding.md) + [ # 「Amazon ECS にデプロイ」する変数 ](deploy-action-ecs-variables.md) + [ # 「Amazon ECS にデプロイ」アクション YAML ](deploy-action-ref-ecs.md) ## 「Amazon ECS にデプロイ」アクションで使用されるランタイムイメージ **[Amazon ECS にデプロイ]** アクションは、[[2022 年 11 月の画像]](build-images.md#build.previous-image) で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。 # チュートリアル: Amazon ECS にアプリケーションをデプロイするこのチュートリアルでは、ワークフロー、Amazon ECS、およびその他のいくつかの AWS サービスを使用して、サーバーレスアプリケーションを Amazon Elastic Container Service (Amazon ECS) にデプロイする方法について説明します。デプロイされたアプリケーションは、Apache ウェブサーバー Docker イメージ上にビルドされたシンプルな Hello World ウェブサイトです。このチュートリアルでは、クラスターのセットアップなど必要な準備作業を順を追って説明し、アプリケーションをビルドおよびデプロイするためのワークフローを作成する方法について説明します。 **ヒント** このチュートリアルを進める代わりに、完全な Amazon ECS セットアップを実行するブループリントを使用できます。**[Node.js API with AWS Fargate]** または、**[Java API with AWS Fargate]** ブループリントで使用する必要があります。詳細については、「[ブループリントを使用したプロジェクトの作成](projects-create.md#projects-create-console-template)」を参照してください。 **Topics** + [ ## 前提条件 ](#deploy-tut-ecs-prereqs) + [ ## ステップ 1: AWS ユーザーとをセットアップする AWS CloudShell ](#deploy-tut-ecs-user-cloudshell) + [ ## ステップ 2: プレースホルダーアプリケーションを Amazon ECS にデプロイする ](#deploy-tut-ecs-placeholder) + [ ## ステップ 1: Amazon ECR イメージリポジトリを作成する ](#deploy-tut-ecs-ecr) + [ ## ステップ 4: AWS ロールを作成する ](#deploy-tut-ecs-build-deploy-roles) + [ ## ステップ 5: CodeCatalyst に AWS ロールを追加する ](#deploy-tut-ecs-import-roles) + [ ## ステップ 6: ソースレポジトリを作成する ](#deploy-tut-ecs-source-repo) + [ ## ステップ 7: ソースファイルを追加する ](#deploy-tut-ecs-source-files) + [ ## ステップ 8: ワークフローを作成して実行する ](#deploy-tut-ecs-workflow) + [ ## ステップ 9: ソースファイルを変更する ](#deploy-tut-ecs-change) + [ ## クリーンアップ ](#deploy-tut-ecs-cleanup) ## 前提条件開始する前に: + 接続された AWS アカウントを持つ CodeCatalyst **スペース**が必要です。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。 + スペースには、次の名前の空のプロジェクトが必要です。 ``` codecatalyst-ecs-project ``` このプロジェクトを作成するには、**[ゼロから開始]** オプションを使用します。詳細については、「[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)」を参照してください。 + プロジェクトには、以下と呼ばれる CodeCatalyst **[環境]** が必要です。 ``` codecatalyst-ecs-environment ``` この環境を次のように設定します。 + **[非本番稼働用]** など、任意のタイプを選択します。 + AWS アカウントにを接続します。 + **[デフォルトの IAM ロール]** で、任意のロールを選択します。後で別のロールを指定します。詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」を参照してください。 ## ステップ 1: AWS ユーザーとをセットアップする AWS CloudShell このチュートリアルの最初のステップは、でユーザーを作成し AWS IAM アイデンティティセンター、このユーザーとしてインスタンスを起動 AWS CloudShell することです。このチュートリアルの期間中、CloudShell は開発用コンピュータであり、 AWS リソースとサービスを設定する場所です。チュートリアルを完了したら、このユーザーを削除してください。 **注記** このチュートリアルにルートユーザーを使用しないでください。別のユーザーを作成する必要があります。作成しないと、後で AWS Command Line Interface (CLI) でアクションを実行するときに問題が発生する可能性があります。 IAM アイデンティティセンターユーザーと CloudShell の詳細については、「*AWS IAM アイデンティティセンターユーザーガイド*」と「*AWS CloudShell ユーザーガイド*」を参照してください。 **IAM アイデンティティセンターユーザーを作成するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/singlesignon/](https://console.aws.amazon.com/singlesignon/) で AWS IAM アイデンティティセンターコンソールを開きます。 **注記** CodeCatalyst スペース AWS アカウントに接続されているを使用してサインインしていることを確認してください。スペースに移動し、**[AWS アカウント]** タブを選択することで、接続されているアカウントを確認できます。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。 1. ナビゲーションペインで **[Users]** (ユーザー)、**[Add user]** (ユーザーの追加) の順に選択します。 1. **[ユーザー名]** に次のように入力します。 ``` CodeCatalystECSUser ``` 1. **[パスワード]** で、**[このユーザーと共有できるワンタイムパスワードを生成]** を選択します。 1. **[E メールアドレス]** と **[E メールアドレスを確認]** で、IAM アイデンティティセンターにまだ存在しない E メールアドレスを入力します。 1. **[名]** と **[姓]** で、次のように入力します。 ``` CodeCatalystECSUser ``` 1. **[表示名]** で、自動的に生成された名前を保持します。 ``` CodeCatalystECSUser CodeCatalystECSUser ``` 1. [**次へ**] を選択します。 1. **[グループにユーザーを追加]** ページで、**[次へ]** を選択します。 1. 「**ユーザーを確認と追加**」ページで情報を確認し、**[ユーザーを追加]** を選択します。 **[ワンタイムパスワード]** ダイアログボックスが表示されます。 1. AWS アクセスポータル URL やワンタイムパスワードなど、サインイン情報を **[コピー]** して貼り付けます。 1. [**閉じる**] を選択してください。 **アクセス権限セットを作成するには** このアクセス許可セットは、後で `CodeCatalystECSUser` に割り当てられます。 1. ナビゲーションペインで [**アクセス許可セット**] を選択し、[**アクセス許可セットの作成**] を選択します。 1. **[事前定義されたアクセス許可セットのポリシー]** で **[AdministratorAccess]** を選択します。このポリシーではすべての AWS のサービスアクションに対するアクセス許可が与えられています。 1. [**次へ**] を選択します。 1. 「**アクセス許可セット名**」に、次のように入力します。 ``` CodeCatalystECSPermissionSet ``` 1. [**次へ**] を選択します。 1. [**確認と作成**] ページで情報を確認し、[**グループの作成**] を選択します。 **アクセス許可セットを CodeCatalystECSUser に割り当てるには** 1. ナビゲーションペインでを選択し**AWS アカウント**、現在サインイン AWS アカウントしているの横にあるチェックボックスをオンにします。 1. 「**ユーザーまたはグループを割り当て**」を選択します。 1. **[ユーザー]** タブを選択します。 1. [`CodeCatalystECSUser`] のチェックボックスをオンにします。 1. [**次へ**] を選択します。 1. [`CodeCatalystECSPermissionSet`] のチェックボックスをオンにします。 1. [**次へ**] を選択します。 1. 情報を確認し、[**送信**] を選択します。これで、 `CodeCatalystECSUser`と `CodeCatalystECSPermissionSet`をに割り当て AWS アカウント、それらをバインドしました。 **CodeCatalystECSUser としてサインアウトしてサインインし直すには** 1. サインアウトする前に、 AWS アクセスポータル URL と、のユーザー名とワンタイムパスワードがあることを確認してください`CodeCatalystECSUser`。この情報は、事前にテキストエディタにコピーしておく必要があります。 **注記** この情報がない場合は、IAM アイデンティティセンターの `CodeCatalystECSUser` 詳細ページに移動し、**[パスワードをリセット]**、**[ワンタイムパスワードを生成 [...]]** を選択して、もう一度 **[パスワードをリセットする]** と、画面に情報が表示されます。 1. からサインアウトします AWS。 1. AWS アクセスポータル URL をブラウザのアドレスバーに貼り付けます。 1. `CodeCatalystECSUser` のユーザー名とワンタイムパスワードを使用してサインインします。 1. **[新しいパスワード]** で、パスワードを入力し、**[新しいパスワードを設定]** を選択します。画面に **AWS アカウント** ボックスが表示されます。 1. を選択し**AWS アカウント**、`CodeCatalystECSUser`ユーザーとアクセス許可セット AWS アカウントを割り当てたの名前を選択します。 1. `CodeCatalystECSPermissionSet` の横にある [**管理コンソール**] を選択します。 AWS マネジメントコンソールが表示されます。これで、適切なアクセス許可を使用し、`CodeCatalystECSUser` としてサインインしました。 **AWS CloudShell インスタンスを起動するには** 1. 上部のナビゲーションバー`CodeCatalystECSUser`で、 AWS アイコン () を選択します![\[AWS icon\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/deploy/aws-logo.png)。のメインページ AWS マネジメントコンソールが表示されます。 1. 上部のナビゲーションバーで、 AWS CloudShell アイコン () を選択します![\[CloudShell icon\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/deploy/CloudShell.png)。 CloudShell が開きます。CloudShell 環境が作成されるまで待ちます。 **注記** CloudShell アイコンが表示されない場合は、[CloudShell でサポートされているリージョン](https://docs.aws.amazon.com/cloudshell/latest/userguide/faq-list.html#regions-available)にいることを確認してください。このチュートリアルは、米国西部 (オレゴン) リージョンにいることを前提としています。 **AWS CLI がインストールされていることを確認するには** 1. CloudShell ターミナルで、次のように入力します。 ``` aws --version ``` 1. バージョンが表示されることを確認します。 AWS CLI は現在のユーザー用にすでに設定されているため`CodeCatalystECSUser`、通常どおり、 AWS CLI キーと認証情報を設定する必要はありません。 ## ステップ 2: プレースホルダーアプリケーションを Amazon ECS にデプロイするこのセクションでは、プレースホルダーアプリケーションを Amazon ECS に手動でデプロイします。このプレースホルダーアプリケーションは、ワークフローによってデプロイされた Hello World アプリケーションに置き換えられます。プレースホルダーアプリケーションは Apache Web Server です。 Amazon ECS の詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」を参照してください。プレースホルダーアプリケーションをデプロイするには、以下の一連の手順を実行します。 **タスク実行のロールを作成するには** このロールは、ユーザーに代わって API コールを行うアクセス AWS Fargate 許可を Amazon ECS に付与します。 1. 信頼ポリシーを作成します。 1. で AWS CloudShell、次のコマンドを入力します。 ``` cat > codecatalyst-ecs-trust-policy.json ``` CloudShell ターミナルに点滅するプロンプトが表示されます。 1. プロンプトで、次のコードを入力します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ 1. 最後の角括弧 (`}`) の後にカーソルを置きます。 1. **Enter** と **Ctrl\$1d** を押してファイルを保存し、終了します。 1. タスク実行ロールを作成する方法 ``` aws iam create-role \ --role-name codecatalyst-ecs-task-execution-role \ --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json ``` 1. AWS 管理`AmazonECSTaskExecutionRolePolicy`ポリシーをロールにアタッチします。 ``` aws iam attach-role-policy \ --role-name codecatalyst-ecs-task-execution-role \ --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy ``` 1. ロールの詳細を表示します。 ``` aws iam get-role \ --role-name codecatalyst-ecs-task-execution-role ``` 1. ロールの `"Arn":` 値、例えば `arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role` を書き留めます。この Amazon リソースネーム (ARN) は後で必要になります。 **Amazon ECS クラスターを作成するには** このクラスターには、Apache プレースホルダーアプリケーションと、それ以降は Hello World アプリケーションが含まれます。 1. として`CodeCatalystECSUser`、で空のクラスター AWS CloudShellを作成します。 ``` aws ecs create-cluster --cluster-name codecatalyst-ecs-cluster ``` 1. (オプション) クラスターが正常に作成されたことを確認します。 ``` aws ecs list-clusters ``` `codecatalyst-ecs-cluster` クラスターの ARN が一覧表示され、正常に作成されたことを示します。 **新しいタスク定義ファイルを作成するには** タスク定義ファイルは、DockerHub からプルされた [[Apache 2.4 Web サーバー]](https://hub.docker.com/_/httpd) Docker イメージ (`httpd:2.4`) を実行することを示します。 1. として`CodeCatalystECSUser`、でタスク定義ファイル AWS CloudShellを作成します。 ``` cat > taskdef.json ``` 1. コマンドプロンプトで、以下を貼り付けます。 ``` { "executionRoleArn": "arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role", "containerDefinitions": [ { "name": "codecatalyst-ecs-container", "image": "httpd:2.4", "essential": true, "portMappings": [ { "hostPort": 80, "protocol": "tcp", "containerPort": 80 } ] } ], "requiresCompatibilities": [ "FARGATE" ], "cpu": "256", "family": "codecatalyst-ecs-task-def", "memory": "512", "networkMode": "awsvpc" } ``` 上記のコードで、*[arn:aws:iam::111122223333:role/codecatalyst-ecs-task-execution-role]* を置き換えます。 [タスク実行のロールを作成するには](#deploy-tut-ecs-create-task-execution-role) でメモしたタスク実行ロールの ARN を使用します。 1. 最後の角括弧 (`}`) の後にカーソルを置きます。 1. **Enter** と **Ctrl\$1d** を押してファイルを保存し、終了します。 **Amazon ECS でタスク定義ファイルに登録します。** 1. として`CodeCatalystECSUser`、タスク定義 AWS CloudShellを登録します。 ``` aws ecs register-task-definition \ --cli-input-json file://taskdef.json ``` 1. (オプション) タスク定義が登録されていることを確認します。 ``` aws ecs list-task-definitions ``` `codecatalyst-ecs-task-def` タスク定義が一覧表示されます。 **Amazon ECS サービスを作成するには** Amazon ECS サービスは、Apache プレースホルダーアプリケーションのタスク (および関連する Docker コンテナ) を実行し、その後、Hello World アプリケーションを実行します。 1. `CodeCatalystECSUser` として、Amazon Elastic Container Service コンソールをまだ切り替えていない場合は、切り替えます。 1. 先ほど作成したクラスター「`codecatalyst-ecs-cluster`」を選択します。 1. **[サービス]** タブで、**[作成]** を選択します。 1. **[作成]** ページで、次のとおり設定します。 1. 次に一覧表示されているものを除き、すべてのデフォルト設定を保持します。 1. [**Launch type (起動タイプ)**] で、[**FARGATE**] を選択します。 1. **[タスク定義]** の **[ファミリー]** ドロップダウンリストで、以下を選択します。 `codecatalyst-ecs-task-def` 1. **[サービス名]** に次のように入力します。 ``` codecatalyst-ecs-service ``` 1. **[必要なタスク]** に次のように入力します。 ``` 3 ``` このチュートリアルでは、各タスクが単一の Docker コンテナを起動します。 1. **[ネットワーク]** セクションを展開します。 1. **[VPC]** で、任意の VPC を選択します。 1. **[サブネット]** では、任意のサブネットを選択します。 **注記** サブネットは 1 つだけ指定します。このチュートリアルに必要なのはこれだけです。 **注記** VPC とサブネットがない場合は、作成します。「*Amazon VPC ユーザーガイド*」で、「[VPC を作成](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC)」、「[VPC にサブネットを作成](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet)」を参照してください。 1. **[セキュリティグループ]** で、**[新しいセキュリティグループを作成]** を選択し、次の操作を行います。 1. **[セキュリティグループ名]** に次のように入力します。 ``` codecatalyst-ecs-security-group ``` 1. **[セキュリティグループの説明]** には、次のように入力します。 ``` CodeCatalyst ECS security group ``` 1. [**ルールを追加**] を選択してください。**[タイプ]** の場合は、**[HTTP]** を選択し、**[ソース]**の場合は **[任意の場所]** を選択します。 1. 一番下で **[作成]** を選択します。 1. サービスが作成されるまで待ちます。このプロセスには数分かかることがあります。 1. **[タスク]** タブを選択し、[更新] を選択します。3 つのタスクすべてで、**[前回のステータス]** 列が **[実行中]** に設定されていることを確認します。 **(オプション) Apache プレースホルダーアプリケーションが実行されていることを確認するには** 1. **[タスク]** タブで、3 つのタスクのいずれかを選択します。 1. **[パブリック IP]** フィールドで、**[オープンアドレス]** を選択します。 `It Works!` ページが表示されます。これは、Amazon ECS サービスが Apache イメージで Docker コンテナを起動するタスクを正常に開始したことを示します。チュートリアルのこの時点で、Amazon ECS クラスター、サービス、タスク定義、および Apache プレースホルダーアプリケーションを手動でデプロイしました。これらの項目がすべて整ったら、Apache プレースホルダーアプリケーションをチュートリアルの Hello World アプリケーションに置き換えるワークフローを作成する準備が整いました。 ## ステップ 1: Amazon ECR イメージリポジトリを作成するこのセクションでは、Amazon Elastic Container Registry (Amazon ECR) にプライベートイメージリポジトリを作成します。このリポジトリには、以前にデプロイした Apache プレースホルダーイメージを置き換えるチュートリアルの Docker イメージが保存されます。 Amazon ECR の詳細については、*Amazon Elastic Container Registry User Guide* を参照してください。 **Amazon ECR にイメージリポジトリを作成するには** 1. として`CodeCatalystECSUser`、Amazon ECR に空のリポジトリ AWS CloudShellを作成します。 ``` aws ecr create-repository --repository-name codecatalyst-ecs-image-repo ``` 1. Amazon ECR リポジトリの詳細を表示します。 ``` aws ecr describe-repositories \ --repository-names codecatalyst-ecs-image-repo ``` 1. `“repositoryUri”:` の値、例えば「`111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo`」を書き留めます。ワークフローにリポジトリを追加するときは、後にこれが必要となります。 ## ステップ 4: AWS ロールを作成するこのセクションでは、CodeCatalyst ワークフローが機能するために必要な AWS IAM ロールを作成します。これらのロールは次のとおりです。 + **ビルドロール** – CodeCatalyst ビルドアクション (ワークフロー内) に AWS 、アカウントにアクセスして Amazon ECR と Amazon EC2 に書き込むアクセス許可を付与します。 + **ロールのデプロイ** – CodeCatalyst **Deploy to ECS** アクション (ワークフロー内) に、 AWS アカウント、Amazon ECS、およびその他のいくつかの AWS サービスにアクセスするためのアクセス許可を付与します。 IAM ロールの詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」を参照してください。 **注記** 時間を節約するため、前に一覧表示した 2 つのロールではなく、`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールと呼ばれる 1 つのロールを作成できます。詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールには、セキュリティリスクをもたらす可能性のある非常に広範なアクセス許可があることを理解します。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。このチュートリアルでは、前述の 2 つのロールを作成することを前提としています。ビルドロールとデプロイロールを作成するには、 AWS マネジメントコンソールまたはを使用できます AWS CLI。 ------ #### [ AWS マネジメントコンソール ] ビルドロールとデプロイロールを作成するには、以下の一連の手順を実行します。 **ビルドロールを作成するには** 1. ロールのポリシーを以下の手順で作成します。 1. にサインインします AWS。 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. ナビゲーションペインで、**ポリシー** を選択してください。 1. **[Create policy]** (ポリシーを作成) を選択します。 1. **JSON** タブを選択します。 1. 既存のコードを削除します。 1. 次のコードを貼り付けます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:*", "ec2:*" ], "Resource": "*" } ] } ``` ------ **注記** ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。 ``` "Resource": "*" ``` 1. [**Next: Tags (次へ: タグ)**] を選択します。 1. **[次へ: レビュー]** を選択します。 1. **[名前]** に次のように入力します。 ``` codecatalyst-ecs-build-policy ``` 1. [**Create policy**] (ポリシーの作成) を選択します。これで、アクセス許可ポリシーが作成されました。 1. 次のようにビルドロールを作成します。 1. ナビゲーションペインで **ロール** を選択してから、**ロールを作成する** を選択します。 1. **[カスタム信頼ポリシー]** を選択します。 1. 既存のカスタム信頼ポリシーを削除します。 1. 次の信頼ポリシーを追加します。 1. [**次へ**] を選択します。 1. **[アクセス許可ポリシー]** で `codecatalyst-ecs-build-policy` を検索し、チェックボックスを選択します。 1. [**次へ**] を選択します。 1. **[ロール名]** には、次のように入力します。 ``` codecatalyst-ecs-build-role ``` 1. **[ロールの説明]** には、次のように入力します。 ``` CodeCatalyst ECS build role ``` 1. [**ロールの作成**] を選択してください。これで、アクセス許可ポリシーと信頼ポリシーを持つビルドロールが作成されました。 1. 次のようにビルドロール ARN を取得します。 1. ナビゲーションペインで **Roles (ロール) ** を選択してください。 1. 検索ボックスに、作成したロールの名前 (`codecatalyst-ecs-build-role`) を入力します。 1. 使用するロールを一覧から選択します。ロールの **[概要]** ページが表示されます。 1. 上部で、**[ARN]** 値をコピーします。これは後で必要になります。 **デプロイロールを作成するには** 1. ロールのポリシーを以下の手順で作成します。 1. にサインインします AWS。 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. ナビゲーションペインで、**ポリシー** を選択してください。 1. **[ポリシーを作成]** を選択します。 1. **JSON** タブを選択します。 1. 既存のコードを削除します。 1. 次のコードを貼り付けます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Action":[ "ecs:DescribeServices", "ecs:CreateTaskSet", "ecs:DeleteTaskSet", "ecs:ListClusters", "ecs:RegisterTaskDefinition", "ecs:UpdateServicePrimaryTaskSet", "ecs:UpdateService", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:ModifyRule", "lambda:InvokeFunction", "lambda:ListFunctions", "cloudwatch:DescribeAlarms", "sns:Publish", "sns:ListTopics", "s3:GetObject", "s3:GetObjectVersion", "codedeploy:CreateApplication", "codedeploy:CreateDeployment", "codedeploy:CreateDeploymentGroup", "codedeploy:GetApplication", "codedeploy:GetDeployment", "codedeploy:GetDeploymentGroup", "codedeploy:ListApplications", "codedeploy:ListDeploymentGroups", "codedeploy:ListDeployments", "codedeploy:StopDeployment", "codedeploy:GetDeploymentTarget", "codedeploy:ListDeploymentTargets", "codedeploy:GetDeploymentConfig", "codedeploy:GetApplicationRevision", "codedeploy:RegisterApplicationRevision", "codedeploy:BatchGetApplicationRevisions", "codedeploy:BatchGetDeploymentGroups", "codedeploy:BatchGetDeployments", "codedeploy:BatchGetApplications", "codedeploy:ListApplicationRevisions", "codedeploy:ListDeploymentConfigs", "codedeploy:ContinueDeployment" ], "Resource":"*", "Effect":"Allow" },{"Action":[ "iam:PassRole" ], "Effect":"Allow", "Resource":"*", "Condition":{"StringLike":{"iam:PassedToService":[ "ecs-tasks.amazonaws.com", "codedeploy.amazonaws.com" ] } } }] } ``` ------ **注記** ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用します。その後、リソース名を使用してポリシーをスコープダウンできます。 ``` "Resource": "*" ``` 1. [**Next: Tags (次へ: タグ)**] を選択します。 1. **[次へ: レビュー]** を選択します。 1. **[名前]** に次のように入力します。 ``` codecatalyst-ecs-deploy-policy ``` 1. [**Create policy**] (ポリシーの作成) を選択します。これで、アクセス許可ポリシーが作成されました。 1. 次のようにデプロイロールを作成します。 1. ナビゲーションペインで **ロール** を選択してから、**ロールを作成する** を選択します。 1. **[カスタム信頼ポリシー]** を選択します。 1. 既存のカスタム信頼ポリシーを削除します。 1. 次の信頼ポリシーを追加します。 1. [**次へ**] を選択します。 1. **[アクセス許可ポリシー]** で `codecatalyst-ecs-deploy-policy` を検索し、チェックボックスを選択します。 1. [**次へ**] を選択します。 1. **[ロール名]** には、次のように入力します。 ``` codecatalyst-ecs-deploy-role ``` 1. **[ロールの説明]** には、次のように入力します。 ``` CodeCatalyst ECS deploy role ``` 1. [**ロールの作成**] を選択してください。これで、信頼ポリシーを使用してデプロイロールが作成されました。 1. デプロイロール ARN を次のように取得します。 1. ナビゲーションペインで **Roles (ロール) ** を選択してください。 1. 検索ボックスに、作成したロールの名前 (`codecatalyst-ecs-deploy-role`) を入力します。 1. 使用するロールを一覧から選択します。ロールの **[概要]** ページが表示されます。 1. 上部で、**[ARN]** 値をコピーします。これは後で必要になります。 ------ #### [ AWS CLI ] ビルドロールとデプロイロールを作成するには、以下の一連の手順を実行します。 **両方のロールの信頼ポリシーを作成するには** として`CodeCatalystECSUser`、信頼ポリシーファイル AWS CloudShellを作成します。 1. ファイルを作成します。 ``` cat > codecatalyst-ecs-trust-policy.json ``` 1. ターミナルプロンプトで、次のコードを貼り付けます。 1. 最後の角括弧 (`}`) の後にカーソルを置きます。 1. **Enter** と **Ctrl\$1d** を押してファイルを保存し、終了します。 **ビルドポリシーとビルドロールを作成するには** 1. ビルドポリシーを作成します。 1. として`CodeCatalystECSUser`、でビルドポリシーファイル AWS CloudShellを作成します。 ``` cat > codecatalyst-ecs-build-policy.json ``` 1. プロンプトで、次のようにコード入力します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:*", "ec2:*" ], "Resource": "*" } ] } ``` ------ 1. 最後の角括弧 (`}`) の後にカーソルを置きます。 1. **Enter** と **Ctrl\$1d** を押してファイルを保存し、終了します。 1. ビルドポリシーを以下に追加します AWS。 ``` aws iam create-policy \ --policy-name codecatalyst-ecs-build-policy \ --policy-document file://codecatalyst-ecs-build-policy.json ``` 1. コマンド出力で、例えば「`arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy`」などの `"arn":` 値を書き留めます。この ARN は後で必要になります。 1. ビルドロールーを作成して信頼ポリシーにアタッチします。 ``` aws iam create-role \ --role-name codecatalyst-ecs-build-role \ --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json ``` 1. ビルドポリシーをビルドロールにアタッチします。 ``` aws iam attach-role-policy \ --role-name codecatalyst-ecs-build-role \ --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy ``` *[arn:aws:iam::111122223333:policy/codecatalyst-ecs-build-policy]* が、先ほど説明したビルドポリシーの ARN に置き換えられます。 1. ビルドロールの詳細を表示します。 ``` aws iam get-role \ --role-name codecatalyst-ecs-build-role ``` 1. ロールの `"Arn":` 値、例えば `arn:aws:iam::111122223333:role/codecatalyst-ecs-build-role` を書き留めます。この ARN は後で必要になります。 **デプロイポリシーとデプロイロールを作成するには** 1. デプロイポリシーを作成します。 1. で AWS CloudShell、デプロイポリシーファイルを作成します。 ``` cat > codecatalyst-ecs-deploy-policy.json ``` 1. プロンプトで、次のようにコード入力します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Action":[ "ecs:DescribeServices", "ecs:CreateTaskSet", "ecs:DeleteTaskSet", "ecs:ListClusters", "ecs:RegisterTaskDefinition", "ecs:UpdateServicePrimaryTaskSet", "ecs:UpdateService", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:ModifyRule", "lambda:InvokeFunction", "lambda:ListFunctions", "cloudwatch:DescribeAlarms", "sns:Publish", "sns:ListTopics", "s3:GetObject", "s3:GetObjectVersion", "codedeploy:CreateApplication", "codedeploy:CreateDeployment", "codedeploy:CreateDeploymentGroup", "codedeploy:GetApplication", "codedeploy:GetDeployment", "codedeploy:GetDeploymentGroup", "codedeploy:ListApplications", "codedeploy:ListDeploymentGroups", "codedeploy:ListDeployments", "codedeploy:StopDeployment", "codedeploy:GetDeploymentTarget", "codedeploy:ListDeploymentTargets", "codedeploy:GetDeploymentConfig", "codedeploy:GetApplicationRevision", "codedeploy:RegisterApplicationRevision", "codedeploy:BatchGetApplicationRevisions", "codedeploy:BatchGetDeploymentGroups", "codedeploy:BatchGetDeployments", "codedeploy:BatchGetApplications", "codedeploy:ListApplicationRevisions", "codedeploy:ListDeploymentConfigs", "codedeploy:ContinueDeployment" ], "Resource":"*", "Effect":"Allow" },{"Action":[ "iam:PassRole" ], "Effect":"Allow", "Resource":"*", "Condition":{"StringLike":{"iam:PassedToService":[ "ecs-tasks.amazonaws.com", "codedeploy.amazonaws.com" ] } } }] } ``` ------ **注記** ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。 ``` "Resource": "*" ``` 1. 最後の角括弧 (`}`) の後にカーソルを置きます。 1. **Enter** と **Ctrl\$1d** を押してファイルを保存し、終了します。 1. デプロイポリシーを以下に追加します AWS。 ``` aws iam create-policy \ --policy-name codecatalyst-ecs-deploy-policy \ --policy-document file://codecatalyst-ecs-deploy-policy.json ``` 1. コマンド出力で、例えば「`arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy`」などのデプロイポリシーの `"arn":` 値を書き留めます。この ARN は後で必要になります。 1. デプロイロールを作成して信頼ポリシーをデプロイロールにアタッチします。 ``` aws iam create-role \ --role-name codecatalyst-ecs-deploy-role \ --assume-role-policy-document file://codecatalyst-ecs-trust-policy.json ``` 1. デプロイポリシーをデプロイロールにアタッチします。ここで、*[arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy]* は、前述のデプロイポリシーの ARN に置き換えられます。 ``` aws iam attach-role-policy \ --role-name codecatalyst-ecs-deploy-role \ --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-ecs-deploy-policy ``` 1. デプロイロールの詳細を表示します。 ``` aws iam get-role \ --role-name codecatalyst-ecs-deploy-role ``` 1. ロールの `"Arn":` の値、例えば「`arn:aws:iam::111122223333:role/codecatalyst-ecs-deploy-role`」を書き留めます。この ARN は後で必要になります。 ------ ## ステップ 5: CodeCatalyst に AWS ロールを追加するこのステップでは、ビルドロール (`codecatalyst-ecs-build-role`) を追加し、スペース内の CodeCatalyst アカウント接続にロール (`codecatalyst-ecs-deploy-role`) をデプロイします。 **ビルドロールとデプロイロールをアカウント接続に追加するには** 1. CodeCatalyst で、スペースに移動します。 1. **[AWS アカウント]** を選択します。アカウント接続が一覧表示されます。 1. ビルドロールとデプロイロールを作成したアカウントを表す AWS アカウント接続を選択します。 1. ** AWS 管理コンソールからロールの管理**を選択します。 **[Amazon CodeCatalyst スペースに IAM ロールの追加]** ページが表示されます。ページにアクセスするには、サインインが必要な場合があります。 1. **[IAM で作成した既存のロールを追加]** を選択します。ドロップダウンリストが表示されます。この一覧表示には、`codecatalyst-runner.amazonaws.com` および `codecatalyst.amazonaws.com` サービスプリンシパルを含む信頼ポリシーを持つすべての IAM ロールが表示されます。 1. ドロップダウンリストで [`codecatalyst-ecs-build-role`] を選択し、**[ロールを追加]** を選択します。 **注記** `The security token included in the request is invalid` が表示された場合は、適切なアクセス許可がない可能性があります。この問題を修正するには、からサインアウト AWS して、CodeCatalyst スペースの作成時に使用した AWS アカウントでサインインし直します。 1. **[IAM ロールを追加]** を選択し、**[IAM で作成した既存のロールを追加]** を選択し、ドロップダウンリストから [`codecatalyst-ecs-deploy-role`] を選択します。[**Add role**] を選択します。これで、ビルドロールとデプロイロールをスペースに追加しました。 1. **[Amazon CodeCatalyst 表示名]** の値をコピーします。この値は、ワークフローを作成するときに後で必要になります。 ## ステップ 6: ソースレポジトリを作成するこのステップでは、CodeCatalyst に空のソースリポジトリを作成します。このリポジトリには、タスク定義ファイルなどのチュートリアルのソースファイルが保存されます。ソースリポジトリの詳細については、「[ソースリポジトリを作成する](source-repositories-create.md)」を参照してください。 **ソースリポジトリを作成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクト「`codecatalyst-ecs-project`」に移動します。 1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。 1. **[リポジトリの追加]** を選択し、**[リポジトリの作成]** を選択します。 1. **[リポジトリ名]** に次のように入力します。 ``` codecatalyst-ecs-source-repository ``` 1. **[作成]** を選択します。 ## ステップ 7: ソースファイルを追加するこのセクションでは、Hello World ソースファイルを CodeCatalyst リポジトリ「`codecatalyst-ecs-source-repository`」に追加します。これらは以下で構成されます。 + `index.html` ファイル - ブラウザに Hello World メッセージを表示します。 + Dockerfile – Docker イメージに使用するベースイメージと、それに適用する Docker コマンドについて説明します。 + `taskdef.json` ファイル - クラスターでタスクを起動するときに使用する Docker イメージを定義します。フォルダは次のような構造になっています。 ``` . |— public-html | |— index.html |— Dockerfile |— taskdef.json ``` **注記** 次の手順では、CodeCatalyst コンソールを使用してファイルを追加する方法を示しますが、必要に応じて Git を使用できます。詳細については、「[ソースリポジトリのクローンを作成する](source-repositories-clone.md)」を参照してください。 **Topics** + [ ### index.html ](#deploy-tut-ecs-source-files-index) + [ ### Dockerfile ](#deploy-tut-ecs-source-files-dockerfile) + [ ### taskdef.json ](#deploy-tut-ecs-source-files-taskdef) ### index.html `index.html` ファイルには、ブラウザに Hello World メッセージが表示されます。 **index.html ファイルを追加するには** 1. CodeCatalyst コンソールで、ソースリポジトリ「`codecatalyst-ecs-source-repository`」に移動します。 1. **[ファイル]** で、**[ファイルを作成]** を選択します。 1. **[ファイル名]** に次のように入力します。 ``` public-html/index.html ``` **重要** 同じ名前のフォルダを作成するには、必ず `public-html/` プレフィックスを含めてください。`index.html` は、このフォルダにあることが期待されます。 1. テキストボックスに次のコードを入力します。 ``` Hello World

Hello World

``` 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。 `index.html` は、`public-html` フォルダ内のリポジトリに追加されます。 ### Dockerfile Dockerfile は、使用するベース Docker イメージと、それに適用する Docker コマンドについて説明します。Dockerfile の詳細については、「[Dockerfile リファレンス](https://docs.docker.com/engine/reference/builder/)」を参照してください。ここで指定された Dockerfile は、Apache 2.4 ベースイメージ (`httpd`) を使用することを示します。また、ウェブページを提供する Apache サーバーのフォルダに「`index.html`」というソースファイルをコピーする手順も含まれています。Dockerfile の `EXPOSE` 命令は、コンテナがポート 80 でリッスンしていることを Docker に伝えます。 **Dockerfile を追加するには** 1. ソースリポジトリで、**[ファイルを作成]** を選択します。 1. **[ファイル名]** には、次のように入力します。 ``` Dockerfile ``` ファイル名に拡張子は含めないでください。 **重要** Dockerfile はリポジトリのルートフォルダに存在する必要があります。ワークフローの `Docker build` コマンドは、ワークフローが存在することを期待します。 1. テキストボックスに次のコードを入力します。 ``` FROM httpd:2.4 COPY ./public-html/index.html /usr/local/apache2/htdocs/index.html EXPOSE 80 ``` 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。 Dockerfile がリポジトリに追加されます。 ### taskdef.json このステップで追加した `taskdef.json` ファイルは、[ステップ 2: プレースホルダーアプリケーションを Amazon ECS にデプロイする](#deploy-tut-ecs-placeholder) で既に指定したファイルと同じですが、次の違いがあります。 `image:` フィールド (`httpd:2.4`) でハードコードされた Docker イメージ名を指定する代わりに、ここでのタスク定義は、イメージ「`$REPOSITORY_URI`」と「`$IMAGE_TAG`」を示すためにいくつかの変数を使用します。これらの変数は、後のステップでワークフローを実行するときに、ワークフローのビルドアクションによって生成された実際の値に置き換えられます。タスク定義パラメータに関する詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[タスク定義パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html)」を参照してください。 **taskdef.json ファイルを追加するには** 1. ソースリポジトリで、**[ファイルを作成]** を選択します。 1. **[ファイル名]** には、次のように入力します。 ``` taskdef.json ``` 1. テキストボックスに次のコードを入力します。 ``` { "executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role", "containerDefinitions": [ { "name": "codecatalyst-ecs-container", # The $REPOSITORY_URI and $IMAGE_TAG variables will be replaced # by the workflow at build time (see the build action in the # workflow) "image": $REPOSITORY_URI:$IMAGE_TAG, "essential": true, "portMappings": [ { "hostPort": 80, "protocol": "tcp", "containerPort": 80 } ] } ], "requiresCompatibilities": [ "FARGATE" ], "networkMode": "awsvpc", "cpu": "256", "memory": "512", "family": "codecatalyst-ecs-task-def" } ``` 上記のコードで置き換えます。 *arn:aws:iam::account\$1ID:role/codecatalyst-ecs-task-execution-role* [タスク実行のロールを作成するには](#deploy-tut-ecs-create-task-execution-role) でメモしたタスク実行ロールの ARN を使用します。 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。 `taskdef.json` ファイルをリポジトリに追加します。 ## ステップ 8: ワークフローを作成して実行するこのステップでは、ソースファイルを取得し、Docker イメージにビルドし、そのイメージを Amazon ECS クラスターにデプロイするワークフローを作成します。このデプロイは、既存の Apache プレースホルダーアプリケーションを置き換えます。ワークフローは、連続して実行される次の構成要素で構成されます。 + トリガー – このトリガーは、ソースリポジトリに変更をプッシュすると、ワークフローを自動的に開始します。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + ビルドアクション (`BuildBackend`) – トリガー時に、アクションは Dockerfile を使用して Docker イメージをビルドし、そのイメージを Amazon ECR にプッシュします。ビルドアクションは、`taskdef.json` を正しい `image` フィールド値で更新し、このファイルの出力アーティファクトを作成します。このアーティファクトは、次のデプロイアクションの入力として使用されます。ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。 + デプロイアクション (`DeployToECS`) – ビルドアクションが完了すると、デプロイアクションはビルドアクション (`TaskDefArtifact`) によって生成された出力アーティファクトを検索し、その内部の `taskdef.json` を見つけて Amazon ECS サービスに登録します。その後、サービスは `taskdef.json` ファイルの指示に従って、Amazon ECS クラスター内で 3 つの Amazon ECS タスク、および関連付けられた Hello World Docker コンテナを実行します。 **ワークフローを作成するには** 1. CodeCatalyst コンソールのナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフローを作成]** を選択します。 1. **[ソースリポジトリ]** で、`codecatalyst-ecs-source-repository` を選択します。 1. **[ブランチ]** で、`main` を選択します。 1. **[作成]** を選択します。 1. YAML サンプルコードを削除します。 1. 次の YAML コードを追加します。 **注記** 次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。このセクションを省略する場合は、環境の **[デフォルト IAM ロール]** フィールドで指定されたロールに、[ステップ 5: CodeCatalyst に AWS ロールを追加する](#deploy-tut-ecs-import-roles) で記述されている両方のロールのアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 ``` Name: codecatalyst-ecs-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: BuildBackend: Identifier: aws/build@v1 Environment: Name: codecatalyst-ecs-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-ecs-build-role Inputs: Sources: - WorkflowSource Variables: - Name: REPOSITORY_URI Value: 111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo - Name: IMAGE_TAG Value: ${WorkflowSource.CommitId} Configuration: Steps: #pre_build: - Run: echo Logging in to Amazon ECR... - Run: aws --version - Run: aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-west-2.amazonaws.com #build: - Run: echo Build started on `date` - Run: echo Building the Docker image... - Run: docker build -t $REPOSITORY_URI:latest . - Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG #post_build: - Run: echo Build completed on `date` - Run: echo Pushing the Docker images... - Run: docker push $REPOSITORY_URI:latest - Run: docker push $REPOSITORY_URI:$IMAGE_TAG # Replace the variables in taskdef.json - Run: find taskdef.json -type f | xargs sed -i "s|\$REPOSITORY_URI|$REPOSITORY_URI|g" - Run: find taskdef.json -type f | xargs sed -i "s|\$IMAGE_TAG|$IMAGE_TAG|g" - Run: cat taskdef.json # The output artifact will be a zip file that contains a task definition file. Outputs: Artifacts: - Name: TaskDefArtifact Files: - taskdef.json DeployToECS: DependsOn: - BuildBackend Identifier: aws/ecs-deploy@v1 Environment: Name: codecatalyst-ecs-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-ecs-deploy-role Inputs: Sources: [] Artifacts: - TaskDefArtifact Configuration: region: us-west-2 cluster: codecatalyst-ecs-cluster service: codecatalyst-ecs-service task-definition: taskdef.json ``` 上記のコードで置き換えます。 + [前提条件](#deploy-tut-ecs-prereqs) で作成された環境名を持つ *[codecatalyst-ecs-environment]* の両方のインスタンス。 + アカウント接続の表示名を持つ *codecatalyst-account-connection* の両方のインスタンス。表示名は数値である場合があります。詳細については、「[ステップ 5: CodeCatalyst に AWS ロールを追加する](#deploy-tut-ecs-import-roles)」を参照してください。 + [ステップ 4: AWS ロールを作成する](#deploy-tut-ecs-build-deploy-roles) で作成したビルドロールの名前を持つ *[codecatalyst-ecs-build-role]*。 + [ステップ 1: Amazon ECR イメージリポジトリを作成する](#deploy-tut-ecs-ecr) で作成された Amazon ECR リポジトリの URI を持つ *[111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo]* (`Value:` プロパティ内)。 + *[111122223333.dkr.ecr.us-west-2.amazonaws.com]* (`Run: aws ecr` コマンド内) と、イメージサフィックス (`/codecatalyst-ecs-image-repo`) のない Amazon ECR リポジトリの URI。 + [ステップ 4: AWS ロールを作成する](#deploy-tut-ecs-build-deploy-roles) で作成したデプロイロールの名前を持つ *[codecatalyst-ecs-deploy-role]*。 + AWS リージョンコードを含む *us-west-2* の両方のインスタンス。リージョンコードの一覧については、「*AWS 全般のリファレンス*」の「[Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)」を参照してください。 **注記** ビルドロールとデプロイロールを作成しない場合は、*[codecatalyst-ecs-build-role]* と *[codecatalyst-ecs-deploy-role]* を `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールの名前に置き換えます。このロールの詳細については、「[ステップ 4: AWS ロールを作成する](#deploy-tut-ecs-build-deploy-roles)」を参照してください。 **ヒント** 前のワークフローコードに示されている `find` および `sed` コマンドを使用してリポジトリとイメージ名を更新する代わりに、この目的のために **[Render Amazon ECS タスク定義]** アクションを使用できます。詳細については、「[Amazon ECS タスク定義の変更](render-ecs-action.md)」を参照してください。 1. (オプション) **[検証]** を選択して、コミットする前に YAML コードが有効であることを確認します。 1. **[コミット]** を選択します。 1. **[コミットワークフロー]** ダイアログボックスで、次のように入力します。 1. **[コミットメッセージ]** の場合、テキストを削除して次のように入力します。 ``` Add first workflow ``` 1. **[レポジトリ]** に `codecatalyst-ecs-source-repository` を選択します。 1. **[ブランチ名]** で、main を選択します。 1. **[コミット]** を選択します。これでワークフローが作成されました。ワークフローの先頭で定義されているトリガーにより、ワークフローの実行が自動的に開始されます。具体的には、`workflow.yaml` ファイルをソースリポジトリにコミット (およびプッシュ) すると、トリガーによってワークフローの実行が開始します。 **ワークフロー実行の進行状況を表示するには** 1. CodeCatalyst コンソールのナビゲーションペインで、**[CI/CD]** を選択し、**[ワークフロー]** を選択します。 1. 先ほど作成したワークフロー「`codecatalyst-ecs-workflow`」を選択します。 1. **[BuildBackend]** を選択すると、ビルドの進行状況が表示されます。 1. **[DeployToECS]** を選択してデプロイの進行状況を確認します。実行の詳細を表示する方法については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。 **デプロイを確認するには** 1. Amazon ECS クラシックコンソール ([https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/)) を開きます。 1. `codecatalyst-ecs-cluster` でクラスターを選択します。 1. [**タスク**] タブを選択します。 1. 3 つのタスクのいずれかを選択します。 1. **[パブリック IP]** フィールドで、**[オープンアドレス]** を選択します。ブラウザに「Hello World」ページが表示され、Amazon ECS サービスがアプリケーションを正常にデプロイしたことを示します。 ## ステップ 9: ソースファイルを変更するこのセクションでは、ソースリポジトリ内の `index.html` ファイルを変更します。この変更により、ワークフローは新しい Docker イメージをビルドし、コミット ID でタグ付けして Amazon ECR にプッシュし、Amazon ECS にデプロイします。 **index.html を変更するには** 1. CodeCatalyst コンソールのナビゲーションペインで、**[コード]** を選択し、**[ソースリポジトリ]** を選択し、リポジトリ「`codecatalyst-ecs-source-repository`」を選択します。 1. [`public-html`] を選択し、[`index.html`] を選択します。 `index.html` の内容が表示されます。 1. **[編集]** を選択します。 1. 行 14 で、`Hello World` テキストを `Tutorial complete!` に変更します。 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。コミットにより、新しいワークフローの実行が開始します。 1. (オプション) ソースリポジトリのメインページに移動し、**[コミットを表示]** を選択し、`index.html` 変更のコミット ID を書き留めます。 1. デプロイの進行状況を確認します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. `codecatalyst-ecs-workflow` を選択して最新の実行を表示します。 1. **BuildBackend**、および **DeployToECS** を選択して、ワークフローの実行の進行状況を確認します。 1. 次のように、アプリケーションが更新されていることを確認します。 1. Amazon ECS クラシックコンソール ([https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/)) を開きます。 1. `codecatalyst-ecs-cluster` でクラスターを選択します。 1. [**タスク**] タブを選択します。 1. 3 つのタスクのいずれかを選択します。 1. **[パブリック IP]** フィールドで、**[オープンアドレス]** を選択します。 `Tutorial complete!` ページが表示されます。 1. (オプション) で AWS、Amazon ECR コンソールに切り替え、新しい Docker イメージにステップ 6 のコミット ID がタグ付けされていることを確認します。 ## クリーンアップこのチュートリアルで使用されているファイルとサービスをクリーンアップして、料金が発生しないようにします。で AWS マネジメントコンソール、次の順序でクリーンアップします。 1. Amazon ECS で、以下を実行します。 1. `codecatalyst-ecs-service` を削除します。 1. `codecatalyst-ecs-cluster` を削除します。 1. `codecatalyst-ecs-task-definition` の登録を解除します。 1. Amazon ECR で、`codecatalyst-ecs-image-repo` を削除します。 1. Amazon EC2 で、`codecatalyst-ecs-security-group` を削除します。 1. IAM アイデンティティセンターで削除します。 1. `CodeCatalystECSUser` 1. `CodeCatalystECSPermissionSet` CodeCatalyst コンソールで、次のようにクリーンアップします。 1. `codecatalyst-ecs-workflow` を削除します。 1. `codecatalyst-ecs-environment` を削除します。 1. `codecatalyst-ecs-source-repository` を削除します。 1. `codecatalyst-ecs-project` を削除します。このチュートリアルでは、CodeCatalyst ワークフローと Amazon ECS へのデプロイアクションを使用してアプリケーションを **[Amazon ECS サービスにデプロイ]** する方法について説明します。 # 「Amazon ECS にデプロイ」アクションの追加次の手順を使用して、**[Amazon ECS にデプロイ]** アクションをワークフローに追加します。 ------ #### [ Visual ] **ビジュアルエディタを使用して「Amazon ECS にデプロイ」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[Amazon ECS にデプロイ]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[Amazon ECS にデプロイ]** を選択します。[アクションの詳細] ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。 + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「Amazon ECS にデプロイ」アクション YAML](deploy-action-ref-ecs.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して「Amazon ECS にデプロイ」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[Amazon ECS にデプロイ]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[Amazon ECS にデプロイ]** を選択します。[アクションの詳細] ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。 + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「Amazon ECS にデプロイ」アクション YAML](deploy-action-ref-ecs.md)」に記載されています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 「Amazon ECS にデプロイ」する変数 **[Amazon ECS にデプロイ]** アクションは、実行時に次の変数を生成して設定します。これらは*事前定義済み変数*と呼ばれます。ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください | キー | 値 | | --- | --- | | クラスター | ワークフローの実行中にデプロイされた Amazon ECS クラスターの名前。例: `codecatalyst-ecs-cluster` | | deployment-platform | デプロイプラットフォームの名前。 `AWS:ECS` にハードコードされています。 | | サービス | ワークフローの実行中にデプロイされた Amazon ECS サービスの名前。例: `codecatalyst-ecs-service` | | task-definition-arn | ワークフローの実行中に登録されたタスク定義の Amazon リソースネーム (ARN)。例: `arn:aws:ecs:us-west-2:111122223333:task-definition/codecatalyst-task-def:8`前の例の `:8` は、登録されたリビジョンを示しています。 | | deployment-url | Amazon ECS コンソールの **[イベント]** タブへのリンク。ワークフロー実行に関連付けられた Amazon ECS デプロイの詳細を表示できます。例: `https://console.aws.amazon.com/ecs/home?region=us-west-2#/clusters/codecatalyst-ecs-cluster/services/codecatalyst-ecs-service/events` | | リージョン | ワークフローの実行中ににデプロイ AWS リージョンされたのリージョンコード。例: `us-west-2` | # 「Amazon ECS にデプロイ」アクション YAML 以下は、**[Amazon ECS にデプロイ]** アクションの YAML 定義です。このアクションの使用方法については、「[ワークフローを使用した Amazon ECS へのデプロイ](deploy-action-ecs.md)」を参照してください。このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. ECSDeployAction\$1nn: Identifier: aws/ecs-deploy@v1 DependsOn: - build-action Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - task-definition-artifact Configuration: region: us-east-1 cluster: ecs-cluster service: ecs-service task-definition: task-definition-path force-new-deployment: false|true codedeploy-appspec: app-spec-file-path codedeploy-application: application-name codedeploy-deployment-group: deployment-group-name codedeploy-deployment-description: deployment-description ``` ## ECSDeployAction (必須) アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。デフォルト: `ECSDeployAction_nn`。対応する UI: [設定] タブ/**[アクション表示名]** ## Identifier (*ECSDeployAction*/**Identifier**) (必須) アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。デフォルト: `aws/ecs-deploy@v1`。対応する UI: ワークフロー図/ECSDeployAction \$1nn/**aws/ecs-deploy@v1** ラベル ## DependsOn (*ECSDeployAction*/**DependsOn**) (オプション) このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。対応する UI: [入力] タブ/**[依存 - オプション]** ## Compute (*ECSDeployAction*/**Compute**) (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。対応する UI: *[なし]* ## Type (*ECSDeployAction*/Compute/**Type**) ([Compute](#deploy.action.ecs.computename) が含まれている場合は必須) コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。 + **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ) アクション実行時の柔軟性を目的として最適化されています。 + **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ) アクションの起動速度を最適化しました。コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングタイプ]** ## Fleet (*ECSDeployAction*/Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングフリート]** ## Timeout (*ECSDeployAction*/**Timeout**) (オプション) CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。対応する UI: [設定] タブ/**[タイムアウト - オプション]** ## Environment (*ECSDeployAction*/**Environment**) (必須) アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウントおよびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用してに接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。 **注記** デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。環境タグ付けの詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: [設定] タブ/**[環境]** ## Name (*ECSDeployAction*/Environment/**Name**) ([Environment](#deploy.action.ecs.environment) が含まれている場合は必須) アクションに関連付ける既存の環境の名前を指定します。対応する UI: [設定] タブ/**[環境]** ## Connections (*ECSDeployAction*/Environment/**Connections**) (新しいバージョンのアクションでは任意。古いバージョンでは必須) アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。アカウント接続を指定しない場合: + アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 + デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Name (*ECSDeployAction*/Environment/Connections/**Name**) ([Connections](#deploy.action.ecs.environment.connections) が含まれている場合は必須) アカウント接続の名前を指定します。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Role (*ECSDeployAction*/Environment/Connections/**Role**) ([Connections](#deploy.action.ecs.environment.connections) が含まれている場合は必須) 「**Amazon ECS にデプロイ**」アクションがアクセス AWSとに使用する IAM ロールの名前を指定します。[ロールを CodeCatalyst スペースに追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。 IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーがあることを確認してください。 + 以下のアクセス許可ポリシー: **警告** アクセス許可は、次のポリシーに示すアクセス許可に制限します。より広範なアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Action":[ "ecs:DescribeServices", "ecs:CreateTaskSet", "ecs:DeleteTaskSet", "ecs:ListClusters", "ecs:RegisterTaskDefinition", "ecs:UpdateServicePrimaryTaskSet", "ecs:UpdateService", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:ModifyRule", "lambda:InvokeFunction", "lambda:ListFunctions", "cloudwatch:DescribeAlarms", "sns:Publish", "sns:ListTopics", "s3:GetObject", "s3:GetObjectVersion", "codedeploy:CreateApplication", "codedeploy:CreateDeployment", "codedeploy:CreateDeploymentGroup", "codedeploy:GetApplication", "codedeploy:GetDeployment", "codedeploy:GetDeploymentGroup", "codedeploy:ListApplications", "codedeploy:ListDeploymentGroups", "codedeploy:ListDeployments", "codedeploy:StopDeployment", "codedeploy:GetDeploymentTarget", "codedeploy:ListDeploymentTargets", "codedeploy:GetDeploymentConfig", "codedeploy:GetApplicationRevision", "codedeploy:RegisterApplicationRevision", "codedeploy:BatchGetApplicationRevisions", "codedeploy:BatchGetDeploymentGroups", "codedeploy:BatchGetDeployments", "codedeploy:BatchGetApplications", "codedeploy:ListApplicationRevisions", "codedeploy:ListDeploymentConfigs", "codedeploy:ContinueDeployment" ], "Resource":"*", "Effect":"Allow" },{"Action":[ "iam:PassRole" ], "Effect":"Allow", "Resource":"*", "Condition":{"StringLike":{"iam:PassedToService":[ "ecs-tasks.amazonaws.com", "codedeploy.amazonaws.com" ] } } }] } ``` ------ **注記** ロールを初めて使用するとき、リソースポリシーステートメントで次のワイルドカードを使用し、使用可能になった後にリソース名でポリシーをスコープダウンします。 ``` "Resource": "*" ``` + 次のカスタム信頼ポリシー: **注記** 必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]** ## Inputs (*ECSDeployAction*/**Inputs**) (オプション) `Inputs` セクションでは、ワークフローの実行中に `ECSDeployAction` に必要なデータを定義します。 **注記** **[Amazon ECS にデプロイ]** アクションごとに 1 つの入力 (ソースまたはアーティファクト) のみが許可されます。対応する UI: **[入力]** タブ ## Sources (*ECSDeployAction*/Inputs/**Sources**) (タスク定義ファイルがソースリポジトリに保存されている場合は必須) タスク定義ファイルがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。現在サポートされているラベルは、`WorkflowSource` のみです。タスク定義ファイルがソースリポジトリに含まれていない場合は、別のアクションによって生成されたアーティファクトに存在する必要があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。対応する UI: 入力タブ/**[ソース - オプション]** ## Artifacts - input (*ECSDeployAction*/Inputs/**Artifacts**) (タスク定義ファイルが前のアクションの[出力アーティファクト](workflows-working-artifacts-output.md)に保存されている場合は必須) デプロイするタスク定義ファイルが以前のアクションによって生成されたアーティファクトに含まれている場合は、ここでそのアーティファクトを指定します。タスク定義ファイルがアーティファクトに含まれていない場合は、ソースリポジトリに存在する必要があります。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [設定] タブ/**[アーティファクト - オプション]** ## Configuration (*ECSDeployAction*/**Configuration**) (必須) アクションの設定プロパティを定義できるセクション。対応する UI: **[設定]** タブ ## region (Configuration/**region**) (必須) Amazon ECS クラスターとサービスが存在する AWS リージョンを指定します。リージョンコードの一覧については、「*AWS 全般のリファレンス*」の「[Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)」を参照してください。対応する UI: [設定] タブ/**[リージョン]** ## cluster (*ECSDeployAction*/Configuration/**cluster**) (必須) 既存の Amazon ECS クラスターの名前を指定します。**[Amazon ECS にデプロイ]** アクションは、コンテナ化されたアプリケーションをタスクとしてこのクラスターにデプロイします。詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[クラスター](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-clusters)」を参照してください。対応する UI: [設定] タブ/**[クラスター]** ## service (*ECSDeployAction*/Configuration/**service**) (必須) タスク定義ファイルをインスタンス化する既存の Amazon ECS サービスの名前を指定します。このサービスは、`cluster` フィールドで指定されたクラスターの下に存在する必要があります。Amazon ECS サービスの詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS サービスとは](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html)」を参照してください。対応する UI: [設定] タブ/**[サービス]** ## task-definition (*ECSDeployAction*/Configuration/**task-definition**) (必須) 既存のタスク定義ファイルへのパスを指定します。ファイルがソースリポジトリに存在する場合、パスはソースリポジトリのルートフォルダに相対します。ファイルが以前のワークフローアクションのアーティファクトに存在する場合、パスはアーティファクトルートフォルダを基準としています。タスク定義ファイルの詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[タスク定義](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions)」を参照してください。対応する UI: [設定] タブ/**[タスク定義]** ## force-new-deployment (*ECSDeployAction*/Configuration/**force-new-deployment**) (必須) 有効にすると、Amazon ECS サービスはサービス定義を変更せずに新しいデプロイを開始できます。デプロイを強制すると、サービスは現在実行中のすべてのタスクを停止し、新しいタスクを起動します。新しいデプロイの強制の詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[サービスの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service.html)」を参照してください。デフォルト: `false` 対応する UI: [設定] タブ/**[サービスの新しいデプロイを強制する]** ## codedeploy-appspec (*ECSDeployAction*/Configuration/**codedeploy-appspec**) (ブルー/グリーンデプロイを使用するように Amazon ECS サービスを設定している場合は必須。それ以外の場合は省略）既存の CodeDeploy アプリケーション仕様 (AppSpec) ファイルの名前とパスを指定します。このファイルは、CodeCatalyst ソースリポジトリのルートに存在する必要があります。AppSpec ファイルの詳細については、「*AWS CodeDeploy ユーザーガイド*」の「[CodeDeploy アプリケーション指定 (AppSpec)](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html)」を参照してください。 **注記** CodeDeploy 情報を指定するのは、Blue/Green デプロイを実行するように Amazon ECS サービスを設定している場合のみです。ローリング更新デプロイ (デフォルト) の場合、CodeDeploy 情報は省略します。Amazon ECS デプロイの詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS のデプロイタイプ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html)」を参照してください。 **注記** **[CodeDeploy]** フィールドは、ビジュアルエディタで非表示になっている場合があります。表示するには、「[ビジュアルエディタに CodeDeploy フィールドがないのはなぜですか?](troubleshooting-workflows.md#troubleshooting-workflows-codedeploy)」を参照してください。対応する UI: [設定] タブ/**[CodeDeploy AppSpec]** ## codedeploy-application (*ECSDeployAction*/Configuration/**codedeploy-application**) (`codedeploy-appspec` が含まれている場合は必須) 既存の CodeDeploy アプリケーションの名前を指定します。詳細については、「*AWS CodeDeploy ユーザーガイド*」の「[CodeDeploy でアプリケーションを使用する」](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications.html)を参照してください。対応する UI: [設定] タブ/**[CodeDeploy アプリケーション]** ## codedeploy-deployment-group (*ECSDeployAction*/Configuration/**codedeploy-deployment-group**) (`codedeploy-appspec` が含まれている場合は必須) 既存の CodeDeploy デプロイグループの名前を指定します。CodeDeploy デプロイグループの詳細については、「*AWS CodeDeploy ユーザーガイド*」の「[CodeDeploy でのデプロイグループを使用する](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)」を参照してください。対応する UI: [設定] タブ/**[CodeDeploy デプロイグループ]** ## codedeploy-deployment-description (*ECSDeployAction*/Configuration/**codedeploy-deployment-description**) (オプション) このアクションが作成するデプロイの説明を指定します。詳細については、「*AWS CodeDeploy ユーザーガイド*」の「[CodeDeploy でデプロイする](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments.html)」を参照してください。対応する UI: [設定] タブ/**[CodeDeploy デプロイの説明]** # ワークフローを使用して Amazon EKS にデプロイする **ヒント** **[Kubernetes クラスターにデプロイ]** アクションを使用する方法を示すチュートリアルについては、「[チュートリアル: Amazon EKS にアプリケーションをデプロイする](deploy-tut-eks.md)」を参照してください。このセクションでは、CodeCatalyst ワークフローを使用してコンテナ化されたアプリケーションを Kubernetes クラスターにデプロイする方法について説明します。これを実現するには、**[Kubernetes クラスターにデプロイ]** アクションをワークフローに追加する必要があります。このアクションは、1 つ以上の Kubernetes マニフェストファイルを使用して Amazon Elastic Kubernetes Service (EKS) で設定した Kubernetes クラスターにアプリケーションをデプロイします。サンプルマニフェストについては、「[チュートリアル: Amazon EKS にアプリケーションをデプロイする](deploy-tut-eks.md)」の「[deployment.yaml](deploy-tut-eks.md#deploy-tut-eks-source-files-deployment-yml)」を参照してください。 Kubernetes の詳細については、[Kubernetes のドキュメント](https://kubernetes.io/docs/home/)を参照してください。 Amazon EKS の詳細については、「*Amazon EKS ユーザーガイド*」の「[Amazon EKS とは](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)」を参照してください。 **Topics** + [ ## 「Kubernetes クラスターにデプロイ」アクションの仕組み ](#deploy-action-eks-howitworks) + [ ## 「Amazon EKS にデプロイ」アクションで使用されるランタイムイメージ ](#deploy-action-eks-runtime) + [ # チュートリアル: Amazon EKS にアプリケーションをデプロイする ](deploy-tut-eks.md) + [ # 「Kubernetes クラスターにデプロイ」アクションの追加 ](deploy-action-eks-adding.md) + [ # 「Kubernetes クラスターにデプロイ」変数 ](deploy-action-eks-variables.md) + [ # 「Kubernetes クラスターにデプロイ」アクション YAML ](deploy-action-ref-eks.md) ## 「Kubernetes クラスターにデプロイ」アクションの仕組み **[Kubernetes クラスターにデプロイ]** は次のように動作します。 1. ランタイム時に、アクションは、アクションを実行している CodeCatalyst コンピューティングマシンに Kubernetes `kubectl` ユーティリティをインストールします。アクションは、アクションの設定時に指定した Amazon EKS クラスターを指すように `kubectl` を設定します。`kubectl` ユーティリティは、次に `kubectl apply` コマンドを実行するために必要です。 1. アクションは `kubectl apply -f my-manifest.yaml` コマンドを実行します。コマンドは *my-manifest.yaml* の手順を実行して、アプリケーションを一連のコンテナとポッドとして設定済みのクラスターにデプロイします。このコマンドの詳細については、「*Kubernetes リファレンスドキュメント*」の「[kubectl apply](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply)」トピックを参照してください。 ## 「Amazon EKS にデプロイ」アクションで使用されるランタイムイメージ **[Amazon EKS にデプロイ]** アクションは、[[2022 年 11 月の画像]](build-images.md#build.previous-image) で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。 # チュートリアル: Amazon EKS にアプリケーションをデプロイするこのチュートリアルでは、Amazon CodeCatalyst ワークフロー、Amazon EKS、およびその他のいくつかの AWS サービスを使用して、コンテナ化されたアプリケーションを Amazon Elastic Kubernetes Service にデプロイする方法について説明します。デプロイされたアプリケーションはシンプルな「Hello, World\$1」です。Apache ウェブサーバー Docker イメージ上にビルドされたウェブサイト。このチュートリアルでは、開発マシンや Amazon EKS クラスターのセットアップなど必要な準備作業を説明し、アプリケーションをビルドしてクラスターにデプロイするワークフローの作成方法を説明します。最初のデプロイが完了すると、チュートリアルでアプリケーションソースを変更するように指示されます。この変更により、新しい Docker イメージがビルドされ、新しいリビジョン情報を使用して Docker イメージリポジトリにプッシュされます。その後、Docker イメージの新しいリビジョンが Amazon EKS にデプロイされます。 **ヒント** このチュートリアルを進める代わりに、完全な Amazon EKS セットアップを実行するブループリントを使用できます。**[EKS App Deployment]** ブループリントを使用する必要があります。詳細については、「[ブループリントを使用したプロジェクトの作成](projects-create.md#projects-create-console-template)」を参照してください。 **Topics** + [ ## 前提条件 ](#deploy-tut-eks-prereqs) + [ ## ステップ 1: 開発マシンをセットアップする ](#deploy-tut-eks-dev-env-create) + [ ## ステップ 2: Amazon EKS クラスターを作成する ](#deploy-tut-eks-cluster) + [ ## ステップ 3: Amazon ECR イメージリポジトリを作成する ](#deploy-tut-eks-ecr) + [ ## ステップ 4: ソースファイルを追加する ](#deploy-tut-eks-source-files) + [ ## ステップ 5: AWS ロールを作成する ](#deploy-tut-eks-roles) + [ ## ステップ 6: CodeCatalyst に AWS ロールを追加する ](#deploy-tut-eks-import-roles) + [ ## ステップ 7: ConfigMap を更新する ](#deploy-tut-eks-configmap) + [ ## ステップ 8: ワークフローを作成して実行する ](#deploy-tut-eks-workflow) + [ ## ステップ 9: ソースファイルを変更する ](#deploy-tut-eks-change) + [ ## クリーンアップ ](#deploy-tut-eks-cleanup) ## 前提条件このチュートリアルを開始する前に: + 接続された AWS アカウントを持つ Amazon CodeCatalyst **スペース**が必要です。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。 + スペースには、次の名前の空のプロジェクトが必要です。 ``` codecatalyst-eks-project ``` このプロジェクトを作成するには、**[ゼロから開始]** オプションを使用します。詳細については、「[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)」を参照してください。 + プロジェクトには、次の名前の空白の CodeCatalyst **[ソースリポジトリ]** が必要です。 ``` codecatalyst-eks-source-repository ``` 詳細については、「[CodeCatalyst のソースリポジトリでコードを保存し、共同作業を行うソースリポジトリでコードを保存して共同作業を行う](source.md)」を参照してください。 + プロジェクトには、CodeCatalyst CI/CD **環境** (開発環境ではない) が必要です。 ``` codecatalyst-eks-environment ``` この環境を次のように設定します。 + **[非本番稼働用]** など、任意のタイプを選択します。 + AWS アカウントを接続します。 + **[デフォルトの IAM ロール]** で、任意のロールを選択します。後で別のロールを指定します。詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」を参照してください。 ## ステップ 1: 開発マシンをセットアップするこのチュートリアルの最初のステップは、このチュートリアル全体で使用するいくつかのツールを使用して開発マシンを設定することです。これらのロールは次のとおりです。 + `eksctl` ユーティリティ – クラスター作成用 + `kubectl` ユーティリティ – `eksctl` の前提条件 + AWS CLI - の前提条件でもあります。 `eksctl` これらのツールは、既存の開発マシンにインストールすることも、クラウドベースの CodeCatalyst 開発環境を使用することもできます。CodeCatalyst 開発環境の利点は、スピンアップとテイクダウンが簡単で、他の CodeCatalyst サービスと統合されているため、このチュートリアルをより少ないステップで実行できます。このチュートリアルでは、CodeCatalyst 開発環境を使用することを前提としています。次の手順では、CodeCatalyst 開発環境を起動し、必要なツールを使用して設定する簡単な方法について説明しますが、詳細な手順が必要な場合は、次を参照してください。 + このガイドの「[開発環境の作成](devenvironment-create.md)」を参照してください。 + 「**Amazon EKS ユーザーガイド**」の「[kubectl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」。 + 「**Amazon EKS ユーザーガイド**」の「[eksctl のインストールまたはアップグレード](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)」。 + 「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLIの最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」。 **新しい開発環境を起動するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクト「`codecatalyst-eks-project`」に移動します。 1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。 1. ソースリポジトリの名前「`codecatalyst-eks-source-repository`」を選択します。 1. 上部近くで **[開発環境を作成]** を選択し、**[AWS Cloud9 (ブラウザで)]** を選択します。 1. **[既存のブランチで作業]** と **[メイン]** が選択されていることを確認してから、**[作成]** を選択します。開発環境が新しいブラウザタブで起動し、リポジトリ (`codecatalyst-eks-source-repository`) がそこにクローンされます。 **kubectl をインストールして設定するには** 1. 開発環境ターミナルで、次のように入力します。 ``` curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.18.9/2020-11-02/bin/linux/amd64/kubectl ``` 1. 次のように入力します。 ``` chmod +x ./kubectl ``` 1. 次のように入力します。 ``` mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin ``` 1. 次のように入力します。 ``` echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc ``` 1. 次のように入力します。 ``` kubectl version --short --client ``` 1. バージョンが表示されることを確認します。 `kubectl` がインストールされました。 **eksctl をインストールして設定するには** **注記** `kubectl` を代わりに使用できるため、`eksctl` は必須ではありません。ただし、`eksctl` にはクラスター設定の多くを自動化する利点があるため、このチュートリアルで推奨されるツールです。 1. 開発環境ターミナルで、次のように入力します。 ``` curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp ``` 1. 次のように入力します。 ``` sudo cp /tmp/eksctl /usr/bin ``` 1. 次のように入力します。 ``` eksctl version ``` 1. バージョンが表示されることを確認します。 `eksctl` がインストールされました。 **AWS CLI がインストールされていることを確認するには** 1. 開発環境ターミナルで、次のように入力します。 ``` aws --version ``` 1. バージョンが表示され、 AWS CLI がインストールされていることを確認します。残りの手順を完了して、にアクセスするために必要なアクセス許可 AWS CLI を持つを設定します AWS。 **を設定するには AWS CLI** AWS サービスへのアクセスを許可するには、アクセスキーとセッショントークン AWS CLI を使用してを設定する必要があります。以下の手順では、キーとトークンを簡単に設定できますが、詳細な手順が必要な場合は、「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLIの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)」を参照してください。 1. IAM アイデンティティセンターユーザーを次のように作成します。 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/singlesignon/](https://console.aws.amazon.com/singlesignon/) で AWS IAM アイデンティティセンターコンソールを開きます。 (IAM アイデンティティセンターにサインインしたことがない場合は、**[有効化]** を選択する必要があります。) **注記** CodeCatalyst スペース AWS アカウントに接続されているを使用してサインインしてください。スペースに移動し、**[AWS アカウント]** タブを選択することで、接続されているアカウントを確認できます。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。 1. ナビゲーションペインで **[Users]** (ユーザー)、**[Add user]** (ユーザーの追加) の順に選択します。 1. **[ユーザー名]** に次のように入力します。 ``` codecatalyst-eks-user ``` 1. **[パスワード]** で、**[このユーザーと共有できるワンタイムパスワードを生成]** を選択します。 1. **[E メールアドレス]** と **[E メールアドレスを確認]** で、IAM アイデンティティセンターにまだ存在しない E メールアドレスを入力します。 1. **[名（ローマ字）]** に次のように入力します。 ``` codecatalyst-eks-user ``` 1. **[姓（ローマ字）]** に次のように入力します。 ``` codecatalyst-eks-user ``` 1. **[表示名]** では、以下を維持します。 ``` codecatalyst-eks-user codecatalyst-eks-user ``` 1. [**次へ**] を選択します。 1. **[グループにユーザーを追加]** ページで、**[次へ]** を選択します。 1. 「**ユーザーを確認と追加**」ページで情報を確認し、**[ユーザーを追加]** を選択します。 **[ワンタイムパスワード]** ダイアログボックスが表示されます。 1. **[コピー]** を選択し、サインイン情報をテキストファイルに貼り付けます。サインイン情報は、 AWS アクセスポータル URL、ユーザー名、ワンタイムパスワードで構成されます。 1. [**閉じる**] を選択してください。 1. 次のようにアクセス権限セットを作成します。 1. ナビゲーションペインで [**アクセス許可セット**] を選択し、[**アクセス許可セットの作成**] を選択します。 1. **[事前定義されたアクセス許可セットのポリシー]** で **[AdministratorAccess]** を選択します。このポリシーではすべての AWS のサービスアクションに対するアクセス許可が与えられています。 1. [**次へ**] を選択します。 1. **[アクセス許可セット名]** で、`AdministratorAccess` を削除して次のように入力します。 ``` codecatalyst-eks-permission-set ``` 1. [**次へ**] を選択します。 1. [**確認と作成**] ページで情報を確認し、[**グループの作成**] を選択します。 1. アクセス許可セットを次のように `codecatalyst-eks-user` に設定します。 1. ナビゲーションペインでを選択し**AWS アカウント**、現在サインイン AWS アカウントしているの横にあるチェックボックスをオンにします。 1. 「**ユーザーまたはグループを割り当て**」を選択します。 1. **[ユーザー]** タブを選択します。 1. [`codecatalyst-eks-user`] のチェックボックスをオンにします。 1. [**次へ**] を選択します。 1. [`codecatalyst-eks-permission-set`] のチェックボックスをオンにします。 1. [**次へ**] を選択します。 1. 情報を確認し、[**送信**] を選択します。これで、 `codecatalyst-eks-user`と `codecatalyst-eks-permission-set`をに割り当て AWS アカウント、それらをバインドしました。 1. 次のように、`codecatalyst-eks-user` のアクセスキーとセッショントークンを取得します。 1. アクセス AWS ポータル URL と、のユーザー名およびワンタイムパスワードがあることを確認します`codecatalyst-eks-user`。この情報は、事前にテキストエディタにコピーしておく必要があります。 **注記** この情報がない場合は、IAM アイデンティティセンターの `codecatalyst-eks-user` 詳細ページに移動し、**[パスワードをリセット]**、**[ワンタイムパスワードを生成 [...]]** を選択して、もう一度 **[パスワードをリセットする]** と、画面に情報が表示されます。 1. からサインアウトします AWS。 1. AWS アクセスポータル URL をブラウザのアドレスバーに貼り付けます。 1. 次の情報でサインインします。 + **ユーザー名**: ``` codecatalyst-eks-user ``` + **パスワード**: *one-time-password* 1. **[新しいパスワードを設定]** で、新しいパスワードを入力し、**[新しいパスワードを設定]** を選択します。画面に **AWS アカウント** ボックスが表示されます。 1. **AWS アカウント** を選択し、 AWS アカウントユーザーとアクセス許可セットを割り当てた `codecatalyst-eks-user` の名前を選択します。 1. `codecatalyst-eks-permission-set` の隣にある **[コマンドラインまたはプログラムによるアクセス]** を選択します。 1. ページの中央にあるコマンドをコピーします。次のような内容です。 ``` export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" export AWS_SESSION_TOKEN="session-token" ``` ...ここでは *[session-token]* は長いランダムな文字列です。 1. 次のように AWS CLI、アクセスキーとセッショントークンをに追加します。 1. CodeCatalyst 開発環境に戻ります。 1. ターミナルプロンプトで、コピーしたコマンドを貼り付けます。[Enter] キーを押します。これで、アクセスキーとセッショントークン AWS CLI を使用してを設定しました。を使用して AWS CLI 、このチュートリアルに必要なタスクを完了できるようになりました。 **重要** このチュートリアル中に次のようなメッセージが表示される場合: `Unable to locate credentials. You can configure credentials by running "aws configure".` または: `ExpiredToken: The security token included in the request is expired` ... AWS CLI セッションの有効期限が切れているためです。この場合、`aws configure` コマンドは*実行しないでください*。代わりに、`Obtain codecatalyst-eks-user's access key and session token` で始まるこの手順のステップ 4 の手順を使用して、セッションを更新します。 ## ステップ 2: Amazon EKS クラスターを作成するこのセクションでは、Amazon EKS にクラスターを作成します。以下の手順では、`eksctl` を使用してクラスターを素早く作成する方法について説明しますが、詳細な手順が必要な場合は、次を参照してください。 + 「**Amazon EKS ユーザーガイド**」の「[eksctl の使用開始](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)」または + 「**Amazon EKS ユーザーガイド**」の「[コンソールと AWS CLIの開始方法](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html) 」(このトピックでは、クラスター作成用の `kubectl` 手順について説明します) **注記** [[プライベートクラスター]](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html) は、Amazon EKS との CodeCatalyst 統合ではサポートされていません。 **[開始する前に]** 開発マシンで次のタスクを完了していることを確認します。 + `eksctl` ユーティリティをインストールする。 + `kubectl` ユーティリティをインストールする。 + をインストール AWS CLI し、アクセスキーとセッショントークンを使用して設定しました。これらのタスクを完了する方法の詳細については、「[ステップ 1: 開発マシンをセットアップする](#deploy-tut-eks-dev-env-create)」を参照してください。 **クラスターを作成するには** **重要** クラスターが正しく設定されないため、Amazon EKS サービスのユーザーインターフェイスを使用してクラスターを作成しないでください。以下のステップで説明されているように、`eksctl` ユーティリティを使用します。 1. 開発環境に移動します。 1. クラスターおよびノードを作成する ``` eksctl create cluster --name codecatalyst-eks-cluster --region us-west-2 ``` コードの説明は以下のとおりです。 + *[codecatalyst-eks-cluster]* は、クラスターに付ける名前に置き換えられます。 + *[us-west-2]* を、ご利用のリージョンに置き換えます。 10～20 分後、次のようなメッセージが表示されます。 `EKS cluster "codecatalyst-eks-cluster" in "us-west-2" region is ready` **注記** AWS がクラスターを作成中に複数の `waiting for CloudFormation stack` メッセージが表示されます。これは通常の動作です。 1. クラスターが正常に作成されたことを確認します。 ``` kubectl cluster-info ``` クラスターが正常に作成されたことを示す次のようなメッセージが表示されます。 ``` Kubernetes master is running at https://long-string.gr7.us-west-2.eks.amazonaws.com CoreDNS is running at https://long-string.gr7.us-west-2.eks.amazonaws.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy ``` ## ステップ 3: Amazon ECR イメージリポジトリを作成するこのセクションでは、Amazon Elastic Container Registry (Amazon ECR) にプライベートイメージリポジトリを作成します。このリポジトリには、チュートリアル用の Docker イメージが保存されます。 Amazon ECR の詳細については、*Amazon Elastic Container Registry User Guide* を参照してください。 **Amazon ECR にイメージリポジトリを作成するには** 1. 開発環境に移動します。 1. Amazon ECR に空白のリポジトリを作成します。 ``` aws ecr create-repository --repository-name codecatalyst-eks-image-repo ``` *[codecatalyst-eks-image-repo]* を Amazon ECR リポジトリに付ける名前に置き換えます。このチュートリアルでは、リポジトリに「`codecatalyst-eks-image-repo`」と名前を付けていることを前提としています。 1. Amazon ECR リポジトリの詳細を表示します。 ``` aws ecr describe-repositories \ --repository-names codecatalyst-eks-image-repo ``` 1. `“repositoryUri”:` の値、例えば「`111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo`」を書き留めます。ワークフローにリポジトリを追加するときは、後にこれが必要となります。 ## ステップ 4: ソースファイルを追加するこのセクションでは、ソースリポジトリ (`codecatalyst-eks-source-repository`) にアプリケーションソースファイルを追加します。これらは以下で構成されます。 + `index.html` ファイル – 「Hello, World\$1」を表示します。ブラウザのメッセージ。 + Dockerfile – Docker イメージに使用するベースイメージと、それに適用する Docker コマンドについて説明します。 + `deployment.yaml` ファイル – Kubernetes サービスとデプロイを定義する Kubernetes マニフェスト。フォルダは次のような構造になっています。 ``` |— codecatalyst-eks-source-repository |— Kubernetes |— deployment.yaml |— public-html | |— index.html |— Dockerfile ``` **Topics** + [ ### index.html ](#deploy-tut-eks-source-files-index) + [ ### Dockerfile ](#deploy-tut-eks-source-files-dockerfile) + [ ### deployment.yaml ](#deploy-tut-eks-source-files-deployment-yml) ### index.html `index.html` ファイルには「Hello, World\$1」と表示されます。ブラウザのメッセージ。 **index.html ファイルを追加するには** 1. 開発環境に移動します。 1. `codecatalyst-eks-source-repository` に「`public-html`」という名前のフォルダを作成します。 1. `/public-html` に「`index.html`」という名前のファイルを次の内容で作成します。 ``` Hello World

Hello, World!

``` 1. ターミナルプロンプトで、次のように入力します。 ``` cd /projects/codecatalyst-eks-source-repository ``` 1. 追加、コミット、プッシュ: ``` git add . git commit -m "add public-html/index.html" git push ``` `index.html` は、`public-html` フォルダ内のリポジトリに追加されます。 ### Dockerfile Dockerfile は、使用するベース Docker イメージと、それに適用する Docker コマンドについて説明します。Dockerfile の詳細については、「[Dockerfile リファレンス](https://docs.docker.com/engine/reference/builder/)」を参照してください。ここで指定された Dockerfile は、Apache 2.4 ベースイメージ (`httpd`) を使用することを示します。また、ウェブページを提供する Apache サーバーのフォルダに「`index.html`」というソースファイルをコピーする手順も含まれています。Dockerfile の `EXPOSE` 命令は、コンテナがポート 80 でリッスンしていることを Docker に伝えます。 **Dockerfile を追加するには** 1. `codecatalyst-eks-source-repository` に「`Dockerfile`」という名前のファイルを次の内容で作成します。 ``` FROM httpd:2.4 COPY ./public-html/index.html /usr/local/apache2/htdocs/index.html EXPOSE 80 ``` ファイル名に拡張子は含めないでください。 **重要** Dockerfile はリポジトリのルートフォルダに存在する必要があります。ワークフローの `Docker build` コマンドは、ワークフローが存在することを期待します。 1. 追加、コミット、プッシュ: ``` git add . git commit -m "add Dockerfile" git push ``` Dockerfile がリポジトリに追加されます。 ### deployment.yaml このセクションでは、リポジトリに `deployment.yaml` ファイルを追加します。`deployment.yaml` ファイルは、Kubernetes マニフェストであり、実行する 2 つの Kubernetes リソースタイプまたは*種類*、つまり「サービス」と「デプロイ」を定義します。 + 「サービス」はロードバランサーを Amazon EC2 にデプロイします。ロードバランサーには、「Hello, World\$1」を参照するために使用できるインターネット向けパブリック URL と標準ポート (ポート 80) が用意されています。アプリケーションをデプロイします。 + 「デプロイ」は 3 つのポッドをデプロイし、各ポッドには「Hello, World\$1」を含む Docker コンテナが含まれます。アプリケーションをデプロイします。3 つのポッドは、クラスターの作成時に作成されたノードにデプロイされます。このチュートリアルのマニフェストは短いですが、マニフェストにはポッド、ジョブ、ingress、ネットワークポリシーなど、任意の数の Kubernetes リソースタイプを含めることができます。さらに、デプロイが複雑な場合は、複数のマニフェストファイルを使用できます。 **deployment.yaml ファイルを追加するには** 1. `codecatalyst-eks-source-repository` に、「`Kubernetes`」という名前のフォルダを作成します。 1. `/Kubernetes` に「`deployment.yaml`」という名前のファイルを次の内容で作成します。 ``` apiVersion: v1 kind: Service metadata: name: my-service labels: app: my-app spec: type: LoadBalancer selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 80 --- apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment labels: app: my-app spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: codecatalyst-eks-container # The $REPOSITORY_URI and $IMAGE_TAG placeholders will be replaced by actual values supplied by the build action in your workflow image: $REPOSITORY_URI:$IMAGE_TAG ports: - containerPort: 80 ``` 1. 追加、コミット、プッシュ: ``` git add . git commit -m "add Kubernetes/deployment.yaml" git push ``` `deployment.yaml` ファイルは、`Kubernetes` というフォルダのリポジトリに追加されます。これで、すべてのソースファイルが追加されました。少し時間を取って作業を再確認し、すべてのファイルを正しいフォルダに配置してください。フォルダは次のような構造になっています。 ``` |— codecatalyst-eks-source-repository |— Kubernetes |— deployment.yaml |— public-html | |— index.html |— Dockerfile ``` ## ステップ 5: AWS ロールを作成するこのセクションでは、CodeCatalyst ワークフローが機能するために必要な AWS IAM ロールを作成します。これらのロールは次のとおりです。 + **ビルドロール** – CodeCatalyst ビルドアクション (ワークフロー内) に AWS 、アカウントにアクセスして Amazon ECR と Amazon EC2 に書き込むためのアクセス許可を付与します。 + **ロールのデプロイ** – CodeCatalyst **Deploy to Kubernetes クラスター**アクション (ワークフロー内) に AWS 、アカウントと Amazon EKS へのアクセス許可を付与します。 IAM ロールの詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」を参照してください。 **注記** 時間を節約するため、前に一覧表示した 2 つのロールではなく、`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールと呼ばれる 1 つのロールを作成できます。詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールには、セキュリティリスクをもたらす可能性のある非常に広範なアクセス許可があることを理解します。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。このチュートリアルでは、前述の 2 つのロールを作成することを前提としています。ビルドロールとデプロイロールを作成するには、以下の一連の手順を実行します。 **1. 両方のロールの信頼ポリシーを作成するには** 1. 開発環境に移動します。 1. 次の内容で、`Cloud9-long-string` ディレクトリに「`codecatalyst-eks-trust-policy.json`」という名前のファイルを作成します。 **2. ビルドロールのビルドポリシーを作成するには** + 次の内容で、`Cloud9-long-string` ディレクトリに「`codecatalyst-eks-build-policy.json`」という名前のファイルを作成します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:*", "ec2:*" ], "Resource": "*" } ] } ``` ------ **注記** ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。 ``` "Resource": "*" ``` **3. デプロイロールにデプロイポリシーを作成するには** + 次の内容で、`Cloud9-long-string` ディレクトリに「`codecatalyst-eks-deploy-policy.json`」という名前のファイルを作成します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:ListClusters" ], "Resource": "*" } ] } ``` ------ **注記** ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。 ``` "Resource": "*" ``` これで、開発環境に 3 つのポリシードキュメントが追加されました。ディレクトリ構造は次のようになります。 ``` |— Cloud9-long-string |— .c9 |— codecatalyst-eks-source-repository |— Kubernetes |— public-html |— Dockerfile codecatalyst-eks-build-policy.json codecatalyst-eks-deploy-policy.json codecatalyst-eks-trust-policy.json ``` **4. ビルドポリシーをに追加するには AWS** 1. 開発環境ターミナルで、次のように入力します。 ``` cd /projects ``` 1. 次のように入力します。 ``` aws iam create-policy \ --policy-name codecatalyst-eks-build-policy \ --policy-document file://codecatalyst-eks-build-policy.json ``` 1. **[Enter]** キーを押します。 1. コマンド出力で、例えば「`arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy`」などの `"arn":` 値を書き留めます。この ARN は後で必要になります。 **5. デプロイポリシーをに追加するには AWS** 1. 次のように入力します。 ``` aws iam create-policy \ --policy-name codecatalyst-eks-deploy-policy \ --policy-document file://codecatalyst-eks-deploy-policy.json ``` 1. **[Enter]** キーを押します。 1. コマンド出力で、例えば「`arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy`」などのデプロイポリシーの `"arn":` 値を書き留めます。この ARN は後で必要になります。 **6. ビルドロールを作成するには** 1. 次のように入力します。 ``` aws iam create-role \ --role-name codecatalyst-eks-build-role \ --assume-role-policy-document file://codecatalyst-eks-trust-policy.json ``` 1. **[Enter]** キーを押します。 1. 次のように入力します。 ``` aws iam attach-role-policy \ --role-name codecatalyst-eks-build-role \ --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy ``` *[arn:aws:iam::111122223333:policy/codecatalyst-eks-build-policy]* が、先ほど説明したビルドポリシーの ARN に置き換えられます。 1. **[Enter]** キーを押します。 1. ターミナルプロンプトで、次のように入力します。 ``` aws iam get-role \ --role-name codecatalyst-eks-build-role ``` 1. **[Enter]** キーを押します。 1. ロールの `"Arn":` の値、例えば「`arn:aws:iam::111122223333:role/codecatalyst-eks-build-role`」を書き留めます。この ARN は後で必要になります。 **7. デプロイロールを作成するには** 1. 次のように入力します。 ``` aws iam create-role \ --role-name codecatalyst-eks-deploy-role \ --assume-role-policy-document file://codecatalyst-eks-trust-policy.json ``` 1. **[Enter]** キーを押します。 1. 次のように入力します。 ``` aws iam attach-role-policy \ --role-name codecatalyst-eks-deploy-role \ --policy-arn arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy ``` *[arn:aws:iam::111122223333:policy/codecatalyst-eks-deploy-policy]* が、先ほど説明したデプロイポリシーの ARN に置き換えられます。 1. **[Enter]** キーを押します。 1. 次のように入力します。 ``` aws iam get-role \ --role-name codecatalyst-eks-deploy-role ``` 1. **[Enter]** キーを押します。 1. ロールの `"Arn":` の値、例えば「`arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role`」を書き留めます。この ARN は後で必要になります。これで、ビルドとデプロイのロールが作成され、その ARN が記録されました。 ## ステップ 6: CodeCatalyst に AWS ロールを追加するこのステップでは、スペースに接続 AWS アカウントしたにビルドロール (`codecatalyst-eks-build-role`) を追加し、ロール (`codecatalyst-eks-deploy-role`) をデプロイします。これにより、ロールをワークフローで使用できるようになります。 **ビルドロールとデプロイロールをに追加するには AWS アカウント** 1. CodeCatalyst コンソールで、スペースに移動します。 1. 上部にある **[設定]** をクリックします。 1. ナビゲーションペインで、**[AWS アカウント]** を選択します。アカウントの一覧が表示されます。 1. **Amazon CodeCatalyst の表示名**列で、ビルドロールとデプロイロールを作成した AWS アカウントの表示名をコピーします。(数値である可能性があります。) この値は、ワークフローを作成するときに後で必要になります。 1. 表示名を選択します。 1. ** AWS 管理コンソールからロールの管理**を選択します。 **[Amazon CodeCatalyst スペースに IAM ロールの追加]** ページが表示されます。ページにアクセスするには、サインインが必要な場合があります。 1. **[IAM で作成した既存のロールを追加]** を選択します。ドロップダウンリストが表示されます。この一覧表示には、ビルドロールとデプロイロール、および `codecatalyst-runner.amazonaws.com` と `codecatalyst.amazonaws.com` サービスプリンシパルを含む信頼ポリシーを持つ他の IAM ロールが表示されます。 1. ドロップダウンリストから追加します。 + `codecatalyst-eks-build-role` + `codecatalyst-eks-deploy-role` **注記** `The security token included in the request is invalid` が表示された場合は、適切なアクセス許可がない可能性があります。この問題を修正するには、からサインアウト AWS して、CodeCatalyst スペースの作成時に使用した AWS アカウントで再度サインインします。 1. CodeCatalyst コンソールに戻り、ページを更新します。ビルドロールとデプロイロールが **[IAM ロール]** の下に表示されるようになりました。これらのロールが CodeCatalyst ワークフローで使用できるようになりました。 ## ステップ 7: ConfigMap を更新する **[Kubernetes クラスターにデプロイ]** アクション (ワークフロー内) にクラスターにアクセスして操作できるようにするには、[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールを Kubernetes `ConfigMap` ファイルに追加する必要があります。このタスクは、`eksctl` または `kubectl` を使用できます。 **eksctl を使用して Kubernetes ConfigMap ファイルを設定するには** + 開発環境ターミナルで、次のように入力します。 ``` eksctl create iamidentitymapping --cluster codecatalyst-eks-cluster --arn arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role --group system:masters --username codecatalyst-eks-deploy-role --region us-west-2 ``` コードの説明は以下のとおりです。 + *codecatalyst-eks-cluster* は、Amazon EKS クラスターのクラスター名に置き換えられます。 + *[arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role]* は、[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールの ARN に置き換えられます。 + *[codecatalyst-eks-deploy-role]* (`--username` の隣) は、[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールの名前に置き換えられます。 **注記** デプロイロールを作成しない場合は、*[codecatalyst-eks-deploy-role]* を `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールの名前に置き換えます。このロールの詳細については、「[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles)」を参照してください。 + *[us-west-2]* を、ご利用のリージョンに置き換えます。このコマンドの詳細については、[[IAM ユーザーとロールの管理]](https://eksctl.io/usage/iam-identity-mappings/) を参照してください。次のようなメッセージが表示されます。 ``` 2023-06-09 00:58:29 [ℹ] checking arn arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role against entries in the auth ConfigMap 2023-06-09 00:58:29 [ℹ] adding identity "arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role" to auth ConfigMap ``` **kubectl を使用して Kubernetes ConfigMap ファイルを設定するには** 1. 開発環境ターミナルで、次のように入力します。 ``` kubectl edit configmap -n kube-system aws-auth ``` ConfigMap ファイルが画面に表示されます。 1. 赤い斜体でテキストを追加します。 ``` # Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. # apiVersion: v1 data: mapRoles: | - groups: - system:bootstrappers - system:nodes rolearn: arn:aws:iam::111122223333:role/eksctl-codecatalyst-eks-cluster-n-NodeInstanceRole-16BC456ME6YR5 username: system:node:{{EC2PrivateDNSName}} - groups: - system:masters rolearn: arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role username: codecatalyst-eks-deploy-role mapUsers: | [] kind: ConfigMap metadata: creationTimestamp: "2023-06-08T19:04:39Z" managedFields: ... ``` コードの説明は以下のとおりです。 + *[arn:aws:iam::111122223333:role/codecatalyst-eks-deploy-role]* は、[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールの ARN に置き換えられます。 + *[codecatalyst-eks-deploy-role]* (`username:` の隣) は、[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールの名前に置き換えられます。 **注記** デプロイロールを作成しない場合は、*[codecatalyst-eks-deploy-role]* を `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールの名前に置き換えます。このロールの詳細については、「[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles)」を参照してください。詳細については、「**Amazon EKS ユーザーガイド**」の「[クラスターへの IAM プリンシパルアクセスを有効化](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)」を参照してください。これで、デプロイロールが付与され、さらには Kubernetes クラスターに **[Amazon EKS にデプロイ]** アクション、`system:masters` アクセス許可が付与されました。 ## ステップ 8: ワークフローを作成して実行するこのステップでは、ソースファイルを受け取り、Docker イメージにビルドし、Amazon EKS クラスターのツリーポッドにイメージをデプロイするワークフローを作成します。ワークフローは、連続して実行される次の構成要素で構成されます。 + トリガー – このトリガーは、ソースリポジトリに変更をプッシュすると、ワークフローを自動的に開始します。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + ビルドアクション (`BuildBackend`) – トリガー時に、アクションは Dockerfile を使用して Docker イメージをビルドし、そのイメージを Amazon ECR にプッシュします。ビルドアクションは、`deployment.yaml` ファイル内の `$REPOSITORY_URI` および `$IMAGE_TAG` 変数を正しい値で更新し、このファイルと `Kubernetes` フォルダ内の他のすべての出力アーティファクトを作成します。このチュートリアルでは、`Kubernetes` フォルダ内の唯一のファイルは `deployment.yaml` ですが、さらにファイルを含めることができます。このアーティファクトは、次のデプロイアクションの入力として使用されます。ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。 + デプロイアクション (`DeployToEKS`) – ビルドアクションが完了すると、デプロイアクションはビルドアクション (`Manifests`) によって生成された出力アーティファクトを検索し、その内部の `deployment.yaml` ファイルを見つけます。次に、アクションは `deployment.yaml` ファイルの指示に従って 3 つのポッドを実行します。それぞれに 1 つの「Hello, World\$1」が含まれます。Docker コンテナ — Amazon EKS クラスター内。 **ワークフローを作成するには** 1. CodeCatalyst コンソールを移動します。 1. プロジェクト (`codecatalyst-eks-project`) に移動します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフローを作成]** を選択します。 1. **[ソースリポジトリ]** で、`codecatalyst-eks-source-repository` を選択します。 1. **[ブランチ]** で、`main` を選択します。 1. **[作成]** を選択します。 1. YAML サンプルコードを削除します。 1. 次の YAML コードを追加して、新しいワークフロー定義ファイルを作成します。 **注記** ワークフロー定義ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。このセクションを省略する場合は、環境の **[デフォルト IAM ロール]** フィールドで指定されたロールに、[ステップ 6: CodeCatalyst に AWS ロールを追加する](#deploy-tut-eks-import-roles) で記述されている両方のロールのアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 ``` Name: codecatalyst-eks-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: BuildBackend: Identifier: aws/build@v1 Environment: Name: codecatalyst-eks-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-eks-build-role Inputs: Sources: - WorkflowSource Variables: - Name: REPOSITORY_URI Value: 111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo - Name: IMAGE_TAG Value: ${WorkflowSource.CommitId} Configuration: Steps: #pre_build: - Run: echo Logging in to Amazon ECR... - Run: aws --version - Run: aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-west-2.amazonaws.com #build: - Run: echo Build started on `date` - Run: echo Building the Docker image... - Run: docker build -t $REPOSITORY_URI:latest . - Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG #post_build: - Run: echo Build completed on `date` - Run: echo Pushing the Docker images... - Run: docker push $REPOSITORY_URI:latest - Run: docker push $REPOSITORY_URI:$IMAGE_TAG # Replace the variables in deployment.yaml - Run: find Kubernetes/ -type f | xargs sed -i "s|\$REPOSITORY_URI|$REPOSITORY_URI|g" - Run: find Kubernetes/ -type f | xargs sed -i "s|\$IMAGE_TAG|$IMAGE_TAG|g" - Run: cat Kubernetes/* # The output artifact will be a zip file that contains Kubernetes manifest files. Outputs: Artifacts: - Name: Manifests Files: - "Kubernetes/*" DeployToEKS: DependsOn: - BuildBackend Identifier: aws/kubernetes-deploy@v1 Environment: Name: codecatalyst-eks-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-eks-deploy-role Inputs: Artifacts: - Manifests Configuration: Namespace: default Region: us-west-2 Cluster: codecatalyst-eks-cluster Manifests: Kubernetes/ ``` 上記のコードで置き換えます。 + [前提条件](#deploy-tut-eks-prereqs) で作成された環境名を持つ *[codecatalyst-eks-environment]* の両方のインスタンス。 + アカウント接続の表示名を持つ *[codecatalyst-account-connection]* の両方のインスタンス。表示名は数値である場合があります。詳細については、「[ステップ 6: CodeCatalyst に AWS ロールを追加する](#deploy-tut-eks-import-roles)」を参照してください。 + [ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したビルドロールの名前を持つ *[codecatalyst-eks-build-role]*。 + [ステップ 3: Amazon ECR イメージリポジトリを作成する](#deploy-tut-eks-ecr) で作成された Amazon ECR リポジトリの URI を持つ *[111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-eks-image-repo]* (`Value:` プロパティ内)。 + *[111122223333.dkr.ecr.us-west-2.amazonaws.com]* (`Run: aws ecr` コマンド内) と、イメージサフィックス (`/codecatalyst-eks-image-repo`) のない Amazon ECR リポジトリの URI。 + [ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles) で作成したデプロイロールの名前を持つ *[codecatalyst-eks-deploy-role]*。 + AWS リージョンコードを含む *us-west-2* の両方のインスタンス。リージョンコードの一覧については、「*AWS 全般のリファレンス*」の「[Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。 **注記** ビルドロールとデプロイロールを作成しない場合は、*[codecatalyst-eks-build-role]* と *[codecatalyst-eks-deploy-role]* を `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールの名前に置き換えます。このロールの詳細については、「[ステップ 5: AWS ロールを作成する](#deploy-tut-eks-roles)」を参照してください。 1. (オプション) **[検証]** を選択して、コミットする前に YAML コードが有効であることを確認します。 1. **[コミット]** を選択します。 1. **[コミットワークフロー]** ダイアログボックスで、次のように入力します。 1. **[コミットメッセージ]** の場合、テキストを削除して次のように入力します。 ``` Add first workflow ``` 1. **[レポジトリ]** に `codecatalyst-eks-source-repository` を選択します。 1. **[ブランチ名]** で、main を選択します。 1. **[コミット]** を選択します。これでワークフローが作成されました。ワークフローの先頭で定義されているトリガーにより、ワークフローの実行が自動的に開始されます。具体的には、`workflow.yaml` ファイルをソースリポジトリにコミット (およびプッシュ) すると、トリガーによってワークフローの実行が開始します。 **ワークフロー実行の進行状況を表示するには** 1. CodeCatalyst コンソールのナビゲーションペインで、**[CI/CD]** を選択し、**[ワークフロー]** を選択します。 1. 先ほど作成したワークフロー「`codecatalyst-eks-workflow`」を選択します。 1. **[BuildBackend]** を選択すると、ビルドの進行状況が表示されます。 1. **[DeployToEKS]** を選択してデプロイの進行状況を確認します。実行の詳細を表示する方法については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。 **デプロイを確認するには** 1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。 1. 左側の下部近くにある **[ロードバランサー]** を選択します。 1. Kubernetes デプロイの一部として作成されたロードバランサーを選択します。どのロードバランサーを選択するかわからない場合は、**[タグ]** タブで次のタグを探します。 + `kubernetes.io/service-name` + `kubernetes.io/cluster/ekstutorialcluster` 1. 正しいロードバランサーを選択し、**[説明]** タブを選択します。 1. **[DNS 名]** の値をコピーしてブラウザのアドレスバーに貼り付けます。「Hello World\$1」ウェブページがブラウザに表示され、アプリケーションが正常にデプロイされたことを示します。 ## ステップ 9: ソースファイルを変更するこのセクションでは、ソースリポジトリ内の `index.html` ファイルを変更します。この変更により、ワークフローは新しい Docker イメージをビルドし、コミット ID でタグ付けして Amazon ECR にプッシュし、Amazon ECS にデプロイします。 **index.html を変更するには** 1. 開発環境に移動します。 1. ターミナルプロンプトで、ソースリポジトリに変更します。 ``` cd /projects/codecatalyst-eks-source-repository ``` 1. 最新のワークフロー変更をプルします。 ``` git pull ``` 1. `codecatalyst-eks-source-repository/public-html/index.html` を開きます。 1. 行 14 で、`Hello, World!` テキストを `Tutorial complete!` に変更します。 1. 追加、コミット、プッシュ: ``` git add . git commit -m "update index.html title" git push ``` ワークフローの実行が自動的に開始します。 1. (オプション) 以下を入力します。 ``` git show HEAD ``` `index.html` 変更のコミット ID を書き留めます。このコミット ID は、先ほど開始したワークフロー実行によってデプロイされる Docker イメージにタグ付けされます。 1. デプロイの進行状況を確認します。 1. CodeCatalyst コンソールのナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. `codecatalyst-eks-workflow` を選択して最新の実行を表示します。 1. **[BuildBackend]** および **[DeployToEKS]** を選択して、ワークフローの実行の進行状況を確認します。 1. 次のように、アプリケーションが更新されていることを確認します。 1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。 1. 左側の下部近くにある **[ロードバランサー]** を選択します。 1. Kubernetes デプロイの一部として作成されたロードバランサーを選択します。 1. **[DNS 名]** の値をコピーしてブラウザのアドレスバーに貼り付けます。これでチュートリアルは完了です。ウェブページがブラウザに表示され、新バージョンのアプリケーションが正常にデプロイされたことを示します。 1. (オプション) で AWS Amazon ECR コンソールに切り替え、新しい Docker イメージがこの手順のステップ 7 のコミット ID でタグ付けされていることを確認します。 ## クリーンアップこのチュートリアルで使用されるストレージリソースとコンピューティングリソースに対して不必要に課金されないように、環境をクリーンアップする必要があります。 **次をクリーンアップするには：** 1. クラスターを削除する 1. 開発環境ターミナルで、次のように入力します。 ``` eksctl delete cluster --region=us-west-2 --name=codecatalyst-eks-cluster ``` コードの説明は以下のとおりです。 + *[us-west-2]* を、ご利用のリージョンに置き換えます。 + *[codecatalyst-eks-cluster]* は、作成したクラスターの名前に置き換えられます。 5～10 分後、クラスターと関連するリソースは削除されます。これには、 CloudFormation スタック、ノードグループ (Amazon EC2 内）、ロードバランサーが含まれますが、これらに限定されません。 **重要** `eksctl delete cluster` コマンドが機能しない場合は、 AWS 認証情報または`kubectl`認証情報を更新する必要がある場合があります。更新する認証情報がわからない場合は、まず AWS 認証情報を更新します。 AWS 認証情報を更新するには、「[「認証情報が見つかりません」および「ExpiredToken」というエラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-auth-errors-eks)」を参照してください。`kubectl` 認証情報を更新するには、「[「サーバーに接続できません」というエラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-unable-connect-eks)」を参照してください。 1. AWS コンソールで、次のようにクリーンアップします。 1. Amazon ECR で、`codecatalyst-eks-image-repo` を削除します。 1. IAM アイデンティティセンターで削除します。 1. `codecatalyst-eks-user` 1. `codecatalyst-eks-permission-set` 1. IAM で、次を削除します。 + `codecatalyst-eks-build-role` + `codecatalyst-eks-deploy-role` + `codecatalyst-eks-build-policy` + `codecatalyst-eks-deploy-policy` 1. CodeCatalyst コンソールで、次のようにクリーンアップします。 1. `codecatalyst-eks-workflow` を削除します。 1. `codecatalyst-eks-environment` を削除します。 1. `codecatalyst-eks-source-repository` を削除します。 1. 開発環境を削除します。 1. `codecatalyst-eks-project` を削除します。このチュートリアルでは、CodeCatalyst ワークフローと Amazon EKS へのデプロイアクションを使用してアプリケーションを **[Kubernetes にデプロイ]** する方法について説明します。 # 「Kubernetes クラスターにデプロイ」アクションの追加次の手順を使用して、**[Kubernetes クラスターにデプロイ]** アクションをワークフローに追加します。 **[開始する前に]** **[Kubernetes クラスターへのデプロイ]** アクションをワークフローに追加する前に、次の準備が必要です。 **ヒント** これらの前提条件をすばやく設定するには、「[チュートリアル: Amazon EKS にアプリケーションをデプロイする](deploy-tut-eks.md)」の手順に従います。 + Amazon EKS の Kubernetes クラスター。詳細については、「**Amazon EKS ユーザーガイド**」の「[Amazon EKS クラスター](https://docs.aws.amazon.com/eks/latest/userguide/clusters.html)」を参照してください。 + アプリケーションを Docker イメージにアセンブルする方法を説明する Dockerfile が少なくとも 1 つあります。Dockerfile の詳細については、「[Dockerfile リファレンス](https://docs.docker.com/engine/reference/builder/)」を参照してください。 + 少なくとも 1 つの Kubernetes マニフェストファイル。Kubernetes ドキュメントの *[設定ファイル]* または *[設定]* と呼ばれます。詳細については、Kubernetes のドキュメントの「[管理リソース](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/)」を参照してください。 + **[Kubernetes クラスターにデプロイ]** アクションに Amazon EKS クラスターにアクセスして操作できるようにする IAM ロール。詳細については、[「Kubernetes クラスターにデプロイ」アクション YAML](deploy-action-ref-eks.md) の [Role](deploy-action-ref-eks.md#deploy.action.eks.environment.connections.role) トピックを参照してください。このロールを作成したら、次の場所に追加する必要があります。 + Kubernetes ConfigMap ファイル。ConfigMap ファイルにロールを追加する方法については、「**Amazon EKS ユーザーガイド**」の「[クラスターへの IAM プリンシパルアクセスの有効化](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)」を参照してください。 + CodeCatalyst。CodeCatalyst に IAM ロールを追加する方法については、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。 + CodeCatalyst のスペース、プロジェクト、環境。スペースと環境の両方を、アプリケーションをデプロイする AWS アカウントに接続する必要があります。詳細については[スペースを作成する](spaces-create.md)、[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)、および[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)を参照してください。 + CodeCatalyst でサポートされているソースリポジトリ。リポジトリには、アプリケーションソースファイル、Dockerfiles、Kubernetes マニフェストが保存されます。詳細については、「[CodeCatalyst のソースリポジトリでコードを保存し、共同作業を行うソースリポジトリでコードを保存して共同作業を行う](source.md)」を参照してください。 ------ #### [ Visual ] **ビジュアルエディタを使用して「Kubernetes クラスターにデプロイ」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[Kubernetes クラスターにデプロイ]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[Kubernetes クラスターにデプロイ]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。 + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「Kubernetes クラスターにデプロイ」アクション YAML](deploy-action-ref-eks.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して「Kubernetes クラスターにデプロイ」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[Kubernetes クラスターにデプロイ]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[Kubernetes クラスターにデプロイ]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。 + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「Kubernetes クラスターにデプロイ」アクション YAML](deploy-action-ref-eks.md)」に記載されています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 「Kubernetes クラスターにデプロイ」変数 **[Kubernetes クラスターにデプロイ]** アクションは、実行時に次の変数を生成して設定します。これらは*事前定義済み変数*と呼ばれます。ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください | キー | 値 | | --- | --- | | クラスター | ワークフローの実行中にデプロイされた Amazon EKS クラスターの Amazon.com リソースネーム (ARN)。例: `arn:aws:eks:us-west-2:111122223333:cluster/codecatalyst-eks-cluster` | | deployment-platform | デプロイプラットフォームの名前。 `AWS:EKS` にハードコードされています。 | | メタデータ | リザーブド。ワークフローの実行中にデプロイされたクラスターに関連する JSON 形式のメタデータ。 | | 名前空間 | クラスターがデプロイされた Kubernetes ネームスペース。例: `default` | | リソース | リザーブド。ワークフローの実行中にデプロイされたリソースに関連する JSON 形式のメタデータ。 | | server | API サーバーのエンドポイントの名前は、クラスターとの通信に使用できます (`kubectl` などの管理ツールを使用)。 API サービスエンドポイントの詳細については、「**Amazon EKS ユーザーガイド**」の「[Amazon EKS クラスターエンドポイントアクセスコントロール](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html)」を参照してください。例: `https://random-string.gr7.us-west-2.eks.amazonaws.com` | # 「Kubernetes クラスターにデプロイ」アクション YAML **[Kubernetes クラスターにデプロイ]** アクションの YAML 定義を次に示します。このアクションの使用方法については、「[ワークフローを使用して Amazon EKS にデプロイする](deploy-action-eks.md)」を参照してください。このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. DeployToKubernetesCluster\$1nn: Identifier: aws/kubernetes-deploy@v1 DependsOn: - build-action Compute: - Type: EC2 | Lambda - Fleet: fleet-name Timeout: timeout-minutes Environment: Name: environment-name Connections: - Name: account-connection-name Role: DeployToEKS Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - manifest-artifact Configuration: Namespace: namespace Region: us-east-1 Cluster: eks-cluster Manifests: manifest-path ``` ## DeployToKubernetesCluster (必須) アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。デフォルト: `DeployToKubernetesCluster_nn`。対応する UI: [設定] タブ/**[アクション表示名]** ## Identifier (*DeployToKubernetesCluster*/**Identifier**) (必須) アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。デフォルト: `aws/kubernetes-deploy@v1`。対応する UI: ワークフロー図/DeployToKubernetesCluster\$1nn/**aws/kubernetes-deploy@v1** ラベル ## DependsOn (*DeployToKubernetesCluster*/**DependsOn**) (オプション) このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。対応する UI: [入力] タブ/**[依存 - オプション]** ## Compute (*DeployToKubernetesCluster*/**Compute**) (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。対応する UI: *[なし]* ## Type (*DeployToKubernetesCluster*/Compute/**Type**) ([Compute](#deploy.action.eks.computename) が含まれている場合は必須) コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。 + **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ) アクション実行時の柔軟性を目的として最適化されています。 + **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ) アクションの起動速度を最適化しました。コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングタイプ]** ## Fleet (*DeployToKubernetesCluster*/Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングフリート]** ## Timeout (*DeployToKubernetesCluster*/**Timeout**) (オプション) CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。対応する UI: [設定] タブ/**[タイムアウト - オプション]** ## Environment (*DeployToKubernetesCluster*/**Environment**) (必須) アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウントおよびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用してに接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。 **注記** デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。環境タグ付けの詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: [設定] タブ/**[環境]** ## Name (*DeployToKubernetesCluster*/Environment/**Name**) ([Environment](#deploy.action.eks.environment) が含まれている場合は必須) アクションに関連付ける既存の環境の名前を指定します。対応する UI: [設定] タブ/**[環境]** ## Connections (*DeployToKubernetesCluster*/Environment/**Connections**) (新しいバージョンのアクションでは任意。古いバージョンでは必須) アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。アカウント接続を指定しない場合: + アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 + デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Name (*DeployToKubernetesCluster*/Environment/Connections/**Name**) (オプション) アカウント接続の名前を指定します。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Role (*DeployToKubernetesCluster*/Environment/Connections/**Role**) ([Connections](#deploy.action.eks.environment.connections) が含まれている場合は必須) **[Kubernetes クラスターにデプロイ]** アクションがアクセス AWSとに使用する IAM ロールの名前を指定します。[ロールを CodeCatalyst スペースに追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。 IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーがあることを確認してください。 + 以下のアクセス許可ポリシー: **警告** アクセス許可は、次のポリシーに示すアクセス許可に制限します。より広範なアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:ListClusters" ], "Resource": "*" } ] } ``` ------ **注記** ロールを初めて使用するとき、リソースポリシーステートメントで次のワイルドカードを使用し、使用可能になった後にリソース名でポリシーをスコープダウンします。 ``` "Resource": "*" ``` + 次のカスタム信頼ポリシー: このロールが、以下に追加されていることを確認します。 + アカウント接続です。IAM ロールとアカウント接続の追加の詳細については、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。 + Kubernetes ConfigMap です。ConfigMap に IAM ロールを追加する方法の詳細については、`eksctl` ドキュメントの「[IAM ユーザーとロールの管理](https://eksctl.io/usage/iam-identity-mappings/)」を参照してください。 **ヒント** アカウント接続と ConfigMap に IAM ロールを追加する手順については、「[チュートリアル: Amazon EKS にアプリケーションをデプロイする](deploy-tut-eks.md)」も参照してください。 **注記** 必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]** ## Inputs (*DeployToKubernetesCluster*/**Inputs**) ([Connections](#deploy.action.eks.environment.connections) が含まれている場合は必須) `Inputs` セクションでは、ワークフローの実行中に `DeployToKubernetesCluster` に必要なデータを定義します。 **注記** **[Amazon EKS にデプロイ]** アクションごとに 1 つの入力 (ソースまたはアーティファクト) のみが許可されます。対応する UI: **[入力]** タブ ## Sources (*DeployToKubernetesCluster*/Inputs/**Sources**) (マニフェストファイルがソースリポジトリに保存されている場合は必須) Kubernetes マニフェストファイルがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。現在サポートされているラベルは、`WorkflowSource` のみです。マニフェストファイルがソースリポジトリに含まれていない場合、別のアクションによって生成されたアーティファクトに存在する必要があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。対応する UI: 入力タブ/**[ソース - オプション]** ## Artifacts - input (*DeployToKubernetesCluster*/Inputs/**Artifacts**) (マニフェストファイルが前のアクションの [[出力アーティファクト]](workflows-working-artifacts-output.md) に保存されている場合は必須) Kubernetes マニフェストファイルまたはファイルが前のアクションによって生成されたアーティファクトに含まれている場合は、ここでそのアーティファクトを指定します。マニフェストファイルがアーティファクトに含まれていない場合は、ソースリポジトリに存在する必要があります。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [設定] タブ/**[アーティファクト - オプション]** ## Configuration (*DeployToKubernetesCluster*/**Configuration**) (必須) アクションの設定プロパティを定義できるセクション。対応する UI: **[設定]** タブ ## Namespace (*DeployToKubernetesCluster*/Configuration/**Namespace**) (オプション) Kubernetes アプリケーションをデプロイする Kubernetes 名前空間を指定します。クラスターで名前空間を使用しない場合は、`default` を使用します。ネームスペースの詳細については、Kubernetes ドキュメントの「[「Kubernetes 名前空間を使用したクラスターの分割](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#subdividing-your-cluster-using-kubernetes-namespaces)」を参照してください。名前空間を省略すると、`default` の値が使用されます。対応する UI: [設定] タブ/**[名前空間]** ## Region (*DeployToKubernetesCluster*/Configuration/**Region**) (必須) Amazon EKS クラスターとサービスが存在する AWS リージョンを指定します。リージョンコードの一覧については、「*AWS 全般のリファレンス*」の「[Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)」を参照してください。対応する UI: [設定] タブ/**[リージョン]** ## Cluster (*DeployToKubernetesCluster*/Configuration/**Cluster**) (必須) 既存の Amazon EKS クラスターの名前を指定します。**[Kubernetes クラスターにデプロイ]** アクションは、コンテナ化されたアプリケーションをこのクラスターにデプロイします。詳細については、「**Amazon EKS ユーザーガイド**」の「[クラスター](https://docs.aws.amazon.com/eks/latest/userguide/clusters.html)」を参照してください。対応する UI: [設定] タブ/**[クラスター]** ## Manifests (*DeployToKubernetesCluster*/Configuration/**Manifests**) (必須) YAML 形式の Kubernetes マニフェストファイルへのパスを指定します (Kubernetes ドキュメントでは、*[設定ファイル]* 、*[設定ファイル]*、または単に *[設定]* と呼ばれます）。複数のマニフェストファイルを使用している場合は、それらを 1 つのフォルダに配置し、そのフォルダを参照します。マニフェストファイルは Kubernetes によって英数字で処理されるため、処理順序を制御するには、ファイル名の前に必ず数字または文字を増やしてください。例えば、次のようになります。 `00-namespace.yaml` `01-deployment.yaml` マニフェストファイルがソースリポジトリに存在する場合、パスはソースリポジトリのルートフォルダに相対します。ファイルが以前のワークフローアクションのアーティファクトに存在する場合、パスはアーティファクトルートフォルダに相対します。例: `Manifests/` `deployment.yaml` `my-deployment.yml` ワイルドカード (`*`) は使用しないでください。 **注記** [[Helm チャート]](https://helm.sh/docs/topics/charts/) と [[kustomization ファイル]](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/) はサポートされていません。マニフェストファイルの詳細については、Kubernetes ドキュメントの「[リソース設定の整理](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#organizing-resource-configurations)」を参照してください。対応する UI: **[設定]** タブ # CloudFormation スタックのデプロイこのセクションでは、CodeCatalyst ワークフローを使用して AWS CloudFormation スタックをデプロイする方法について説明します。これを行うには、** CloudFormation スタックのデプロイ**アクションをワークフローに追加する必要があります。アクションは、指定したテンプレート AWS に基づいて、リソースの CloudFormation スタックをにデプロイします。テンプレートは、次のようになります。 + CloudFormation テンプレート – 詳細については、[「テンプレートの使用 CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)」を参照してください。 + AWS SAM テンプレート – 詳細については、[AWS Serverless Application Model 「 (AWS SAM) 仕様](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html)」を参照してください。 **注記** AWS SAM テンプレートを使用するには、まず `[sam package](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-package.html)`オペレーションを使用して AWS SAM アプリケーションをパッケージ化する必要があります。Amazon CodeCatalyst ワークフローの一部としてこのパッケージを自動的に実行する方法を示すチュートリアルについては、「[チュートリアル: サーバーレスアプリケーションをデプロイする](deploy-tut-lambda.md)」を参照してください。スタックが既に存在する場合、アクションは CloudFormation `[CreateChangeSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateChangeSet.html)` オペレーションを実行し、次に `[ExecuteChangeSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_ExecuteChangeSet.html)` オペレーションを実行します。その後、アクションは変更がデプロイされるのを待ち、結果に応じて、失敗または成功したものとしてマークします。デプロイするリソースを含む CloudFormation または AWS SAM テンプレートが既にある場合、または AWS SAM やなどのツールを使用してワークフロービルドアクションの一部として自動的に生成する予定がある場合は、 ** CloudFormation スタック**のデプロイアクションを使用します[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html)。 [ビルドアクションの追加](build-add-action.md) 使用できるテンプレートに制限はありません。CloudFormation で作成することも、** CloudFormation スタックのデプロイ**アクションで使用 AWS SAM することもできます。 **ヒント** ** CloudFormation スタックのデプロイアクションを使用してサーバーレスアプリケーションをデプロイ**する方法を示すチュートリアルについては、「」を参照してください[チュートリアル: サーバーレスアプリケーションをデプロイする](deploy-tut-lambda.md)。 **Topics** + [ ## CloudFormation 「スタックをデプロイ」アクションで使用されるランタイムイメージ ](#deploy-action-cfn-runtime) + [ # チュートリアル: サーバーレスアプリケーションをデプロイする ](deploy-tut-lambda.md) + [ # CloudFormation 「スタックのデプロイ」アクションの追加 ](deploy-action-cfn-adding.md) + [ # ロールバックの設定 ](deploy-consumption-enable-alarms.md) + [ # CloudFormation 「スタックをデプロイ」変数 ](deploy-action-cfn-variables.md) + [ # CloudFormation 「スタックをデプロイ」アクション YAML ](deploy-action-ref-cfn.md) ## CloudFormation 「スタックをデプロイ」アクションで使用されるランタイムイメージ ** CloudFormation スタックのデプロイ**アクションは、[2022 年 11 月のイメージ](build-images.md#build.previous-image)で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。 # チュートリアル: サーバーレスアプリケーションをデプロイするこのチュートリアルでは、ワークフローを使用してサーバーレスアプリケーションを CloudFormation スタックとしてビルド、テスト、デプロイする方法について説明します。このチュートリアルのアプリケーションは、「Hello World」メッセージを出力するシンプルなウェブアプリケーションです。これは AWS Lambda 関数と Amazon API Gateway で構成され、の拡張機能である [AWS Serverless Application Model (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) を使用して構築します[CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)。 **Topics** + [ ## 前提条件 ](#deploy-tut-lambda-cfn-prereqs) + [ ## ステップ 1: ソースレポジトリを作成する ](#deploy-tut-lambda-cfn-source) + [ ## ステップ 2: AWS ロールを作成する ](#deploy-tut-lambda-cfn-roles) + [ ## ステップ 3: CodeCatalyst に AWS ロールを追加する ](#deploy-tut-lambda-cfn-roles-add) + [ ## ステップ 4: Amazon S3 バケットを作成する ](#deploy-tut-lambda-cfn-s3) + [ ## ステップ 5: ソースファイルを追加する ](#deploy-tut-lambda-cfn-files) + [ ## ステップ 6: ワークフローを作成して実行する ](#deploy-tut-lambda-cfn-workflow) + [ ## ステップ 7: 変更を行う ](#deploy-tut-lambda-cfn-change) + [ ## クリーンアップ ](#deploy-tut-lambda-cfn-clean-up) ## 前提条件開始する前に: + 接続された AWS アカウントを持つ CodeCatalyst **スペース**が必要です。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。 + スペースには、次の名前の空のプロジェクトが必要です。 ``` codecatalyst-cfn-project ``` このプロジェクトを作成するには、**[ゼロから開始]** オプションを使用します。詳細については、「[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)」を参照してください。 + プロジェクトには、以下と呼ばれる CodeCatalyst **[環境]** が必要です。 ``` codecatalyst-cfn-environment ``` この環境を次のように設定します。 + **[非本番稼働用]** など、任意のタイプを選択します。 + AWS アカウントを接続します。 + **[デフォルトの IAM ロール]** で、任意のロールを選択します。後で別のロールを指定します。詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」を参照してください。 ## ステップ 1: ソースレポジトリを作成するこのステップでは、CodeCatalyst に空のソースリポジトリを作成します。このリポジトリは、Lambda 関数ファイルなどのチュートリアルのソースファイルを保存するために使用されます。ソースリポジトリの詳細については、「[ソースリポジトリを作成する](source-repositories-create.md)」を参照してください。 **ソースリポジトリを作成するには** 1. ナビゲーションペインの CodeCatalyst で **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。 1. **[リポジトリの追加]** を選択し、**[リポジトリの作成]** を選択します。 1. **[リポジトリ名]** に次のように入力します。 ``` codecatalyst-cfn-source-repository ``` 1. **[作成]** を選択します。これで、`codecatalyst-cfn-source-repository` というリポジトリが作成されました。 ## ステップ 2: AWS ロールを作成するこのステップでは、次の IAM AWS ロールを作成します。 + **ロールのデプロイ** – サーバーレスアプリケーションをデプロイする AWS アカウントと CloudFormation サービスにアクセスするアクセス許可を CodeCatalyst **Deploy CloudFormation スタック**アクションに付与します。** CloudFormation スタックのデプロイ**アクションはワークフローの一部です。 + **ビルドロール** – CodeCatalyst ビルドアクションに、 AWS アカウントにアクセスし、サーバーレスアプリケーションパッケージが保存される Amazon S3 に書き込むアクセス許可を付与します。ビルドアクションはワークフローの一部です。 + **スタックロール** – 後で指定する AWS SAM テンプレートで指定されたリソースを読み取って変更するアクセス許可を CloudFormation に付与します。また、CloudWatch にアクセス許可を付与します。 IAM ロールの詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」を参照してください。 **注記** 時間を節約するため、前に一覧表示した 3 つのロールではなく、`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールと呼ばれる 1 つのロールを作成できます。詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールには、セキュリティリスクをもたらす可能性のある非常に広範なアクセス許可があることを理解します。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。このチュートリアルでは、前述の 3 つのロールを作成することを前提としています。 **注記** [[Lambda 実行ロール]](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) も必要ですが、ステップ 5 でワークフローを実行するときに `sam-template.yml` ファイルが作成するため、今すぐ作成する必要はありません。 **デプロイロールを作成するには** 1. ロールのポリシーを以下の手順で作成します。 1. にサインインします AWS。 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. ナビゲーションペインで、**ポリシー** を選択してください。 1. **[Create policy]** (ポリシーを作成) を選択します。 1. **JSON** タブを選択します。 1. 既存のコードを削除します。 1. 次のコードを貼り付けます。 **注記** ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。 ``` "Resource": "*" ``` 1. [**Next: Tags (次へ: タグ)**] を選択します。 1. **[次へ: レビュー]** を選択します。 1. **[名前]** に次のように入力します。 ``` codecatalyst-deploy-policy ``` 1. [**Create policy**] (ポリシーの作成) を選択します。これで、アクセス許可ポリシーが作成されました。 1. 次のようにデプロイロールを作成します。 1. ナビゲーションペインで **ロール** を選択してから、**ロールを作成する** を選択します。 1. **[カスタム信頼ポリシー]** を選択します。 1. 既存のカスタム信頼ポリシーを削除します。 1. 次の信頼ポリシーを追加します。 1. [**次へ**] を選択します。 1. **[アクセス許可ポリシー]** で `codecatalyst-deploy-policy` を検索し、チェックボックスをオンにします。 1. [**次へ**] を選択します。 1. **[ロール名]** には、次のように入力します。 ``` codecatalyst-deploy-role ``` 1. **[ロールの説明]** には、次のように入力します。 ``` CodeCatalyst deploy role ``` 1. [**ロールの作成**] を選択してください。これで、信頼ポリシーとアクセス許可ポリシーを使用してデプロイロールが作成されました。 1. デプロイロール ARN を次のように取得します。 1. ナビゲーションペインで **Roles (ロール) ** を選択してください。 1. 検索ボックスに、作成したロールの名前 (`codecatalyst-deploy-role`) を入力します。 1. 使用するロールを一覧から選択します。ロールの **[概要]** ページが表示されます。 1. 上部で、**[ARN]** 値をコピーします。これで、適切なアクセス許可を持つデプロイロールを作成し、ARN を取得しました。 **ビルドロールを作成するには** 1. ロールのポリシーを以下の手順で作成します。 1. にサインインします AWS。 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. ナビゲーションペインで、**ポリシー** を選択してください。 1. **[Create policy]** (ポリシーを作成) を選択します。 1. **JSON** タブを選択します。 1. 既存のコードを削除します。 1. 次のコードを貼り付けます。 **注記** ロールがワークフローアクションの実行に初めて使用されるときは、リソースポリシーステートメントでワイルドカードを使用し、利用可能になった後にリソース名でポリシーの範囲を絞り込みます。 ``` "Resource": "*" ``` 1. [**Next: Tags (次へ: タグ)**] を選択します。 1. **[次へ: レビュー]** を選択します。 1. **[名前]** に次のように入力します。 ``` codecatalyst-build-policy ``` 1. [**Create policy**] (ポリシーの作成) を選択します。これで、アクセス許可ポリシーが作成されました。 1. 次のようにビルドロールを作成します。 1. ナビゲーションペインで **ロール** を選択してから、**ロールを作成する** を選択します。 1. **[カスタム信頼ポリシー]** を選択します。 1. 既存のカスタム信頼ポリシーを削除します。 1. 次の信頼ポリシーを追加します。 1. [**次へ**] を選択します。 1. **[アクセス許可ポリシー]** で `codecatalyst-build-policy` を検索し、チェックボックスをオンにします。 1. [**次へ**] を選択します。 1. **[ロール名]** には、次のように入力します。 ``` codecatalyst-build-role ``` 1. **[ロールの説明]** には、次のように入力します。 ``` CodeCatalyst build role ``` 1. [**ロールの作成**] を選択してください。これで、信頼ポリシーとアクセス許可ポリシーを使用してビルドロールが作成されました。 1. 次のようにビルドロール ARN を取得します。 1. ナビゲーションペインで **Roles (ロール) ** を選択してください。 1. 検索ボックスに、作成したロールの名前 (`codecatalyst-build-role`) を入力します。 1. 使用するロールを一覧から選択します。ロールの **[概要]** ページが表示されます。 1. 上部で、**[ARN]** 値をコピーします。これで、適切なアクセス許可を持つビルドロールを作成し、その ARN を取得しました。 **スタックロールを作成するには** 1. スタックをデプロイするアカウント AWS を使用してにサインインします。 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. 次のようにスタックロールを作成します。 1. ナビゲーションペインで **Roles (ロール) ** を選択してください。 1. [**ロールの作成**] を選択してください。 1. **[AWS サービス]** を選択してください。 1. **[ユースケース]** セクションで、ドロップダウンリストから **[CloudFormation]** を選択します。 1. **[CloudFormation]** ラジオボタンを選択します。 1. 下部で、**[次へ]** を選択します。 1. 検索ボックスを使用して、次のアクセス許可ポリシーを検索し、それぞれのチェックボックスをオンにします。 **注記** ポリシーを検索してもポリシーが表示されない場合は、**[フィルターをクリア]** を選択して再試行してください。 + **CloudWatchFullAccess** + **AWS CloudFormationFullAccess** + **IAMFullAccess** + **AWS Lambda\$1FullAccess** + **AmazonAPIGatewayAdministrator** + **AmazonS3FullAccess** + **AmazonEC2ContainerRegistryFullAccess** 最初のポリシーでは、CloudWatch へのアクセスを許可し、アラームが発生したときにスタックのロールバックを有効にします。残りのポリシー AWS SAM では、このチュートリアルでデプロイされるスタック内のサービスとリソースへのアクセスをに許可します。詳細については、「*AWS Serverless Application Model デベロッパーガイド*」の「[アクセス許可](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-permissions.html)」を参照してください。 1. [**次へ**] を選択します。 1. **[ロール名]** には、次のように入力します。 ``` codecatalyst-stack-role ``` 1. [**ロールの作成**] を選択してください。 1. 次のように、スタックロールの ARN を取得します。 1. ナビゲーションペインで **Roles (ロール) ** を選択してください。 1. 検索ボックスに、作成したロールの名前 (`codecatalyst-stack-role`) を入力します。 1. 使用するロールを一覧から選択します。 1. **[概要]** セクションの **[ARN]** 値をコピーします。これは後で必要になります。これで、適切なアクセス許可を持つスタックロールを作成し、ARN を取得しました。 ## ステップ 3: CodeCatalyst に AWS ロールを追加するこのステップでは、ビルドロール (`codecatalyst-build-role`) を追加し、スペース内の CodeCatalyst アカウント接続にロール (`codecatalyst-deploy-role`) をデプロイします。 **注記** スタックロール (`codecatalyst-stack-role`) を接続に追加する必要はありません。これは、デプロイロールを使用して、CodeCatalyst と AWS 間で接続が既に確立された*後*、スタックロールが *[CloudFormation]* (CodeCatalyst ではない) で使用されるためです。スタックロールは、CodeCatalyst が AWSにアクセスするために使用するものではないため、アカウント接続に関連付ける必要はありません。 **ビルドロールとデプロイロールをアカウント接続に追加するには** 1. CodeCatalyst で、スペースに移動します。 1. **[AWS アカウント]** を選択します。アカウント接続が一覧表示されます。 1. ビルドロールとデプロイロールを作成したアカウントを表す AWS アカウント接続を選択します。 1. ** AWS 管理コンソールからロールの管理**を選択します。 **[Amazon CodeCatalyst スペースに IAM ロールの追加]** ページが表示されます。ページにアクセスするには、サインインが必要な場合があります。 1. **[IAM で作成した既存のロールを追加]** を選択します。ドロップダウンリストが表示されます。この一覧表示には、`codecatalyst-runner.amazonaws.com` および `codecatalyst.amazonaws.com` サービスプリンシパルを含む信頼ポリシーを持つすべての IAM ロールが表示されます。 1. ドロップダウンリストで [`codecatalyst-build-role`] を選択し、**[ロールを追加]** を選択します。 1. **[IAM ロールを追加]** を選択し、**[IAM で作成した既存のロールを追加]** を選択し、ドロップダウンリストから [`codecatalyst-deploy-role`] を選択します。[**Add role**] を選択します。これで、ビルドロールとデプロイロールをスペースに追加しました。 1. **[Amazon CodeCatalyst 表示名]** の値をコピーします。この値は、ワークフローを作成するときに後で必要になります。 ## ステップ 4: Amazon S3 バケットを作成するこのステップでは、サーバーレスアプリケーションのデプロイパッケージ .zip ファイルを保存する Amazon S3 バケットを作成します。 **Amazon S3 バケットを作成するには** 1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。 1. メインペインで、**[バケットを作成]** を選択します。 1. **[バケット名]** に、次のように入力します。 ``` codecatalyst-cfn-s3-bucket ``` 1. **[AWS リージョン]** で、リージョンを選択します。このチュートリアルは、**[米国西部 (オレゴン) us-west-2]** を選択していることを前提としています。Amazon S3 がサポートしているリージョンについては、「*AWS 全般のリファレンス*」の「[Amazon Simple Storage Service エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/s3.html)」を参照してください。 1. ページ下部にある **[バケットを作成]** ボタンを選択します。これで、米国西部 (オレゴン) us-west-2 リージョンで **codecatalyst-cfn-s3-bucket** という名前のバケットが作成されました。 ## ステップ 5: ソースファイルを追加するこのステップでは、CodeCatalyst ソースリポジトリに複数のアプリケーションソースファイルを追加します。`hello-world` フォルダには、デプロイするアプリケーションファイルが含まれています。`tests` フォルダにはユニットテストが含まれています。フォルダは次のような構造になっています。 ``` . |— hello-world | |— tests | |— unit | |— test-handler.js | |— app.js |— .npmignore |— package.json |— sam-template.yml |— setup-sam.sh ``` ### .npmignore ファイル `.npmignore` ファイルは、アプリケーションパッケージから npm を除外するファイルとフォルダを示します。このチュートリアルでは、npm はアプリケーションの一部ではないため、`tests` フォルダを除外します。 **.npmignore ファイルを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクト「`codecatalyst-cfn-project`」を選択します。 1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。 1. ソースリポジトリのリストから、リポジトリ `codecatalyst-cfn-source-repository` を選択します。 1. **[ファイル]** で、**[ファイルを作成]** を選択します。 1. **[ファイル名]** に次のように入力します。 ``` .npmignore ``` 1. テキストボックスに次のコードを入力します。 ``` tests/* ``` 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。これで、リポジトリのルートに `.npmignore` という名前のファイルが作成されました。 ### package.json ファイル `package.json` ファイルには、プロジェクト名、バージョン番号、説明、依存関係、およびアプリケーションとやり取りして実行する方法を説明するその他の詳細など、Node プロジェクトに関する重要なメタデータが含まれています。このチュートリアルの `package.json` には、依存関係の一覧と `test` スクリプトが含まれています。スクリプトは、次を実行します。 + [[mocha]](https://mochajs.org/) を使用して、テストスクリプトは `hello-world/tests/unit/` で指定されたユニットテストを実行し、[[xunit]]() レポーターを使用して結果を `junit.xml` ファイルに書き込みます。 + [[Istanbul (nyc)]](https://istanbul.js.org/) を使用すると、テストスクリプトは [[clover]](https://openclover.org/doc/manual/4.2.0/general--about-openclover.html) レポーターを使用してコードカバレッジレポート (`clover.xml`) を生成します。詳細については、「Istanbul ドキュメント」の「[代替レポーターの使用](https://istanbul.js.org/docs/advanced/alternative-reporters/#clover)」を参照してください。 **package.json ファイルを追加するには** 1. リポジトリの **[ファイル]** で、**[ファイルを作成]** を選択します。 1. **[ファイル名]** に次のように入力します。 ``` package.json ``` 1. テキストボックスに次のコードを入力します。 ``` { "name": "hello_world", "version": "1.0.0", "description": "hello world sample for NodeJS", "main": "app.js", "repository": "https://github.com/awslabs/aws-sam-cli/tree/develop/samcli/local/init/templates/cookiecutter-aws-sam-hello-nodejs", "author": "SAM CLI", "license": "MIT", "dependencies": { "axios": "^0.21.1", "nyc": "^15.1.0" }, "scripts": { "test": "nyc --reporter=clover mocha hello-world/tests/unit/ --reporter xunit --reporter-option output=junit.xml" }, "devDependencies": { "aws-sdk": "^2.815.0", "chai": "^4.2.0", "mocha": "^8.2.1" } } ``` 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。これで、リポジトリのルートに「`package.json`」という名前のファイルが追加されました。 ### sam-template.yml ファイル `sam-template.yml` ファイルには、Lambda 関数と API Gateway をデプロイし、それらを一緒に設定するための手順が含まれています。テンプレート[AWS Serverless Application Model 仕様](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html)に従っており、 CloudFormation テンプレート仕様を拡張します。は便利な [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) リソースタイプ AWS SAM を提供するため、このチュートリアル AWS SAM では通常のテンプレートの代わりに CloudFormation テンプレートを使用します。このタイプは、基本的な CloudFormation 構文を使用するために通常書き出す必要がある behind-the-scenes の設定を多く実行します。例えば、`AWS::Serverless::Function` は、関数を開始する Lambda 関数、Lambda 実行ロール、イベントソースマッピングを作成します。基本的な CloudFormation を使用して書き込む場合は、これらすべてをコーディングする必要があります。このチュートリアルでは、事前に作成されたテンプレートを使用しますが、ビルドアクションを使用してワークフローの一部として作成できます。詳細については、「[CloudFormation スタックのデプロイ](deploy-action-cfn.md)」を参照してください。 **sam-template.yml ファイルを追加するには** 1. リポジトリの **[ファイル]** で、**[ファイルを作成]** を選択します。 1. **[ファイル名]** に次のように入力します。 ``` sam-template.yml ``` 1. テキストボックスに次のコードを入力します。 ``` AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > serverless-api Sample SAM Template for serverless-api # More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst Globals: Function: Timeout: 3 Resources: HelloWorldFunction: Type: AWS::Serverless::Function # For details on this resource type, see https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction Properties: CodeUri: hello-world/ Handler: app.lambdaHandler Runtime: nodejs12.x Events: HelloWorld: Type: Api # For details on this event source type, see https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api Properties: Path: /hello Method: get Outputs: # ServerlessRestApi is an implicit API created out of the events key under Serverless::Function # Find out about other implicit resources you can reference within AWS SAM at # https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#api HelloWorldApi: Description: "API Gateway endpoint URL for the Hello World function" Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/" HelloWorldFunction: Description: "Hello World Lambda function ARN" Value: !GetAtt HelloWorldFunction.Arn HelloWorldFunctionIamRole: Description: "Implicit Lambda execution role created for the Hello World function" Value: !GetAtt HelloWorldFunctionRole.Arn ``` 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。これで、リポジトリのルートフォルダに「`sam-template.yml`」という名前のファイルが追加されました。 ### setup-sam.sh ファイル `setup-sam.sh` ファイルには、 CLI AWS SAM ユーティリティをダウンロードしてインストールする手順が含まれています。ワークフローは、このユーティリティを使用して `hello-world` ソースをパッケージ化します。 **setup-sam.sh ファイルを追加するには** 1. リポジトリの **[ファイル]** で、**[ファイルを作成]** を選択します。 1. **[ファイル名]** に次のように入力します。 ``` setup-sam.sh ``` 1. テキストボックスに次のコードを入力します。 ``` #!/usr/bin/env bash echo "Setting up sam" yum install unzip -y curl -LO https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip unzip -qq aws-sam-cli-linux-x86_64.zip -d sam-installation-directory ./sam-installation-directory/install; export AWS_DEFAULT_REGION=us-west-2 ``` 上記のコードでは、*[us-west-2]* を AWS リージョンに置き換えます。 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。これで、リポジトリのルートに「`setup-sam.sh`」という名前のファイルが追加されました。 ### app.js ファイル `app.js` には、Lambda 関数のコードが含まれます。このチュートリアルでは、`hello world` コードはテキストを返します。 **app.js ファイルを追加するには** 1. リポジトリの **[ファイル]** で、**[ファイルを作成]** を選択します。 1. **[ファイル名]** に次のように入力します。 ``` hello-world/app.js ``` 1. テキストボックスに次のコードを入力します。 ``` // const axios = require('axios') // const url = 'http://checkip.amazonaws.com/'; let response; /** * * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format * @param {Object} event - API Gateway Lambda Proxy Input Format * * Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html * @param {Object} context * * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html * @returns {Object} object - API Gateway Lambda Proxy Output Format * */ exports.lambdaHandler = async (event, context) => { try { // const ret = await axios(url); response = { 'statusCode': 200, 'body': JSON.stringify({ message: 'hello world', // location: ret.data.trim() }) } } catch (err) { console.log(err); return err; } return response }; ``` 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。これで、「`hello-world`」というフォルダと「`app.js`」というファイルが作成されました。 ### test-handler.js ファイル `test-handler.js` ファイルには、Lambda 関数の単位テストが含まれています。 **test-handler.js ファイルを追加するには** 1. リポジトリの **[ファイル]** で、**[ファイルを作成]** を選択します。 1. **[ファイル名]** に次のように入力します。 ``` hello-world/tests/unit/test-handler.js ``` 1. テキストボックスに次のコードを入力します。 ``` 'use strict'; const app = require('../../app.js'); const chai = require('chai'); const expect = chai.expect; var event, context; describe('Tests index', function () { it('verifies successful response', async () => { const result = await app.lambdaHandler(event, context) expect(result).to.be.an('object'); expect(result.statusCode).to.equal(200); expect(result.body).to.be.an('string'); let response = JSON.parse(result.body); expect(response).to.be.an('object'); expect(response.message).to.be.equal("hello world"); // expect(response.location).to.be.an("string"); }); }); ``` 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。これで、`hello-world/tests/unit` フォルダの下位に「`test-handler.js`」というファイルが追加されました。これで、すべてのソースファイルが追加されました。少し時間を取って作業を再確認し、すべてのファイルを正しいフォルダに配置してください。フォルダは次のような構造になっています。 ``` . |— hello-world | |— tests | |— unit | |— test-handler.js | |— app.js |— .npmignore |— README.md |— package.json |— sam-template.yml |— setup-sam.sh ``` ## ステップ 6: ワークフローを作成して実行するこのステップでは、Lambda ソースコードをパッケージ化し、デプロイするワークフローを作成します。ワークフローは、連続して実行される次の構成要素で構成されます。 + トリガー – このトリガーは、ソースリポジトリに変更をプッシュすると、ワークフローを自動的に開始します。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + テストアクション (`Test`) – トリガー時に、このアクションは [[Node パッケージマネージャー (npm)]](https://www.npmjs.com/) をインストールし、`npm run test` コマンドを実行します。このコマンドは、`package.json` ファイルで定義された `test` スクリプトを実行するように npm に指示します。次に、`test` スクリプトはユニットテストを実行し、テストレポート (`junit.xml`) とコードカバレッジレポート (`clover.xml`) の 2 つのレポートを生成します。詳細については、「[package.json ファイル](#deploy-tut-lambda-cfn-files-package-json)」を参照してください。次に、テストアクションは XML レポートを CodeCatalyst レポートに変換し、テストアクションの **[Reports]** タブの CodeCatalyst コンソールに表示します。テストアクションの詳細については、「[ワークフローを使用したテストワークフローを使用したテスト](test-workflow-actions.md)」を参照してください。 + ビルドアクション (`BuildBackend`) – テストアクションが完了すると、ビルドアクションは CLI AWS SAM をダウンロードしてインストールし、`hello-world`ソースをパッケージ化し、パッケージを Lambda サービスが想定する Amazon S3 バケットにコピーします。アクションは、という新しい AWS SAM テンプレートファイルも出力`sam-template-packaged.yml`し、という出力アーティファクトに配置します`buildArtifact`。ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。 + デプロイアクション (`DeployCloudFormationStack`) – ビルドアクションが完了すると、デプロイアクションはビルドアクション (`buildArtifact`) によって生成された出力アーティファクトを検索し、その中に AWS SAM テンプレートを見つけて、テンプレートを実行します。 AWS SAM テンプレートは、サーバーレスアプリケーションをデプロイするスタックを作成します。 **ワークフローを作成するには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフローを作成]** を選択します。 1. **[ソースリポジトリ]** で、`codecatalyst-cfn-source-repository` を選択します。 1. **[ブランチ]** で、`main` を選択します。 1. **[作成]** を選択します。 1. YAML サンプルコードを削除します。 1. 次の YAML コードを追加します。 **注記** 次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。このセクションを省略する場合は、環境の **[デフォルト IAM ロール]** フィールドで指定されたロールに、[ステップ 2: AWS ロールを作成する](#deploy-tut-lambda-cfn-roles) で記述されている両方のロールのアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 ``` Name: codecatalyst-cfn-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: Test: Identifier: aws/managed-test@v1 Inputs: Sources: - WorkflowSource Outputs: Reports: CoverageReport: Format: CLOVERXML IncludePaths: - "coverage/*" TestReport: Format: JUNITXML IncludePaths: - junit.xml Configuration: Steps: - Run: npm install - Run: npm run test BuildBackend: Identifier: aws/build@v1 DependsOn: - Test Environment: Name: codecatalyst-cfn-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-build-role Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: . ./setup-sam.sh - Run: sam package --template-file sam-template.yml --s3-bucket codecatalyst-cfn-s3-bucket --output-template-file sam-template-packaged.yml --region us-west-2 Outputs: Artifacts: - Name: buildArtifact Files: - "**/*" DeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 DependsOn: - BuildBackend Environment: Name: codecatalyst-cfn-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-deploy-role Inputs: Artifacts: - buildArtifact Sources: [] Configuration: name: codecatalyst-cfn-stack region: us-west-2 role-arn: arn:aws:iam::111122223333:role/StackRole template: ./sam-template-packaged.yml capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND ``` 上記のコードで置き換えます。 + 環境の名前を持つ *[codecatalyst-cfn-environment]* の両方のインスタンス。 + アカウント接続の表示名を持つ *[codecatalyst-account-connection]* の両方のインスタンス。表示名は数値である場合があります。詳細については、「[ステップ 3: CodeCatalyst に AWS ロールを追加する](#deploy-tut-lambda-cfn-roles-add)」を参照してください。 + [ステップ 2: AWS ロールを作成する](#deploy-tut-lambda-cfn-roles) で作成したビルドロールの名前を持つ「*codecatalyst-build-role*」 + [ステップ 4: Amazon S3 バケットを作成する](#deploy-tut-lambda-cfn-s3) で作成した Amazon S3 バケットの名前を持つ *[codecatalyst-cfn-s3-bucket]*。 + Amazon S3 バケットが存在するリージョン (1 番目のインスタンス) とスタックがデプロイされるリージョン (2 番目のインスタンス) を持つ *[us-west-2]* のインスタンスの両方。これらのリージョンは異なる場合があります。このチュートリアルでは、両方のリージョンが `us-west-2` に設定されていることを前提としています。Amazon S3 およびでサポートされているリージョンの詳細については CloudFormation、の[「サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照してください*AWS 全般のリファレンス*。 + [ステップ 2: AWS ロールを作成する](#deploy-tut-lambda-cfn-roles) で作成したデプロイロールの名前を持つ「*codecatalyst-deploy-role*」 + 「[前提条件](#deploy-tut-lambda-cfn-prereqs)」で作成した環境の名前を持つ *[codecatalyst-cfn-environment]*。 + [ステップ 2: AWS ロールを作成する](#deploy-tut-lambda-cfn-roles) で作成したスタックロールの Amazon リソースネーム (ARN) を持つ *[arn:aws:iam::111122223333:role/StackRole]*。 **注記** ビルド、デプロイ、スタックロールを作成しない場合、*codecatalyst-build-role*、*codecatalyst-deploy-role*、および *arn:aws:iam::111122223333:role/StackRole* を `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールの名前または ARN に置き換えます。このロールの詳細については、「[ステップ 2: AWS ロールを作成する](#deploy-tut-lambda-cfn-roles)」を参照してください。前述のコードのプロパティの詳細については、「[CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)」を参照してください。 1. (オプション) **[検証]** を選択して、コミットする前に YAML コードが有効であることを確認します。 1. **[コミット]** を選択します。 1. **[ワークフローをコミット]** ダイアログボックスで、次のように入力します。 1. **[ワークフローファイル名]** は、デフォルトの「`codecatalyst-cfn-workflow`」のままにします。 1. **[コミットメッセージ]** には、次のように入力します。 ``` add initial workflow file ``` 1. **[リポジトリ]** で、**[codecatalyst-cfn-source-repository]** を選択します。 1. **[ブランチ名]** で、**[main]** を選択します。 1. **[コミット]** を選択します。これでワークフローが作成されました。ワークフローの先頭で定義されているトリガーにより、ワークフローの実行が自動的に開始されます。具体的には、`codecatalyst-cfn-workflow.yaml` ファイルをソースリポジトリにコミット (およびプッシュ) すると、トリガーによってワークフローの実行が開始します。 **ワークフロー実行の進行状況を確認するには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. 先ほど作成したワークフロー「`codecatalyst-cfn-workflow`」を選択します。 1. **[実行]** タブを選択します。 1. **[Run ID]** 列で、実行 ID を選択します。 1. **[Test]** を選択して、テストの進行状況を確認します。 1. **[BuildBackend]** を選択すると、ビルドの進行状況が表示されます。 1. **[DeployCloudFormationStack]** を選択してデプロイの進行状況を確認します。実行の詳細を表示する方法については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。 1. **[DeployCloudFormationStack]** アクションが完了したら、以下を実行します。 + ワークフローの実行が成功したら、次の手順に進みます。 + **[Test]** または **[BuildBackend]** ワークフローの実行が失敗した場合は、**[Logs]** を選択して問題をトラブルシューティングします。 + **[DeployCloudFormationStack]** アクションでワークフローの実行が失敗した場合は、デプロイアクションを選択し、**[概要]** タブを選択します。**[CloudFormation イベント]** セクションにスクロールして、詳細なエラーメッセージを表示します。ロールバックが発生した場合は、ワークフローを再実行する前に、の CloudFormation コンソール AWS から`codecatalyst-cfn-stack`スタックを削除します。 **デプロイを確認するには** 1. デプロイが成功したら、上部付近の水平メニューバーから **[変数 (7)]** を選択します。(右側のペインで **[変数]** を選択しないでください)。 1. **[HelloWorldApi]** の横にある `https://` URL をブラウザに貼り付けます。 Lambda 関数からの **[hello world]** JSON メッセージが表示され、ワークフローが Lambda 関数と API Gateway を正常にデプロイおよび設定したことを示します。 **ヒント** CodeCatalyst が、いくつかの細かい設定を持つワークフロー図に、この URL を表示するようにできます。詳細については、「[ワークフロー図でのアプリケーション URL の表示](deploy-app-url.md)」を参照してください。 **ユニットテスト結果とコードカバレッジを検証するには** 1. ワークフロー図で、**[Test]** を選択し、**[Reports]** を選択します。 1. **[TestReport]** を選択してユニットテスト結果を表示するか、**[CoverageReport]** を選択してテスト対象のファイルのコードカバレッジの詳細を表示します。この場合、`app.js` と `test-handler.js` です。 **デプロイされたリソースを確認するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/apigateway/](https://console.aws.amazon.com/apigateway/) で API Gateway コンソールを開きます。 1. AWS SAM テンプレートが作成した **codecatalyst-cfn-stack** API を確認します。API 名は、ワークフロー定義ファイル (`codecatalyst-cfn-workflow.yaml`) の `Configuration/name` の値から取得します。 1. [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/) で AWS Lambda コンソールを開きます。 1. ナビゲーションペインで、**[関数]** を選択します。 1. Lambda 関数「`codecatalyst-cfn-stack-HelloWorldFunction-string`」を選択します。 1. API Gateway が関数のトリガーであることを確認できます。この統合は、リソースタイプによって自動的に設定されました AWS SAM `AWS::Serverless::Function`。 ## ステップ 7: 変更を行うこのステップでは、Lambda ソースコードを変更してコミットします。このコミットにより、新しいワークフロー実行が開始します。この実行では、Lambda コンソールで指定されたデフォルトのトラフィックシフト設定を使用するブルーグリーンスキームで新しい Lambda 関数をデプロイします。 **Lambda ソースを変更するには** 1. CodeCatalyst で、プロジェクトに移動します。 1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。 1. ソースリポジトリ「`codecatalyst-cfn-source-repository`」を選択します。 1. アプリケーションファイルを変更します。 1. `hello-world` フォルダを選択します。 1. `app.js` ファイルを選択します。 1. **[編集]** を選択します。 1. 行 23 において、`hello world` を **Tutorial complete\$1** に変更します。 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。コミットにより、ワークフローの実行が開始します。名前の変更を反映するようにユニットテストを更新していないため、この実行は失敗します。 1. ユニットテストを更新します。 1. `hello-world\tests\unit\test-handler.js` を選択してください。 1. **[編集]** を選択します。 1. 行 19 において、`hello world` を **Tutorial complete\$1** に変更します。 1. **[コミット]** を選択し、再度 **[コミット]** を選択します。コミットにより、もう 1 つのワークフローの実行が開始します。この実行は成功します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. [`codecatalyst-cfn-workflow`] を選択し、**[実行]** を選択します。 1. 最新の実行の実行 ID を選択します。この時点では実行中です。 1. **[Test]**、**[BuildBackend]**、**[DeployCloudFormationStack]** を選択し、ワークフローの実行の進行状況を確認します。 1. ワークフローが完了したら、上部の近くの **[変数 (7)]** を選択します。 1. **[HelloWorldApi]** の横にある `https://` URL をブラウザに貼り付けます。 `Tutorial complete!` メッセージがブラウザに表示されます。これは、アプリケーションが正常にデプロイされたことを示しています。 ## クリーンアップこのチュートリアルで使用されているファイルとサービスをクリーンアップして、料金が発生しないようにします。 **CodeCatalyst コンソールでクリーンアップするには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. `codecatalyst-cfn-workflow` を削除します。 1. `codecatalyst-cfn-environment` を削除します。 1. `codecatalyst-cfn-source-repository` を削除します。 1. `codecatalyst-cfn-project` を削除します。 **でクリーンアップするには AWS マネジメントコンソール** 1. CloudFormation で次のようにクリーンアップします。 1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。 1. `codecatalyst-cfn-stack` を削除します。スタックを削除すると、API Gateway および Lambda サービスからすべてのチュートリアルリソースが削除されます。 1. Amazon S3 で次のようにクリーンアップします。 1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。 1. [`codecatalyst-cfn-s3-bucket`] を選択します。 1. バケットのコンテンツを削除します。 1. バケットを削除します。 1. IAM で次のようにクリーンアップします。 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. `codecatalyst-deploy-policy` を削除します。 1. `codecatalyst-build-policy` を削除します。 1. `codecatalyst-stack-policy` を削除します。 1. `codecatalyst-deploy-role` を削除します。 1. `codecatalyst-build-role` を削除します。 1. `codecatalyst-stack-role` を削除します。このチュートリアルでは、CodeCatalyst ワークフローとデプロイスタックアクションを使用して、サーバーレスアプリケーションを CloudFormation ** CloudFormation スタックとしてデプロイ**する方法を学習しました。 # CloudFormation 「スタックのデプロイ」アクションの追加次の手順を使用して、ワークフローに**スタックのデプロイ CloudFormation **アクションを追加します。 ------ #### [ Visual ] **ビジュアルエディタを使用して CloudFormation 「スタックのデプロイ」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. ** CloudFormation スタックのデプロイ**アクションを検索し、次のいずれかを実行します。 + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + ** CloudFormation スタックをデプロイ **を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。 + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して CloudFormation 「スタックのデプロイ」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. ** CloudFormation スタックのデプロイ**アクションを検索し、次のいずれかを実行します。 + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + ** CloudFormation スタックをデプロイ** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。 + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)」に記載されています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # ロールバックの設定デフォルトでは、**スタックのデプロイ CloudFormation **アクションが失敗すると、はスタック CloudFormation を最後の既知の安定状態にロールバックします。アクションが失敗したときだけでなく、指定された Amazon CloudWatch アラームが発生したときにもロールバックが発生するように動作を変更できます。CloudWatch アラームの使用の詳細については、*Amazon CloudWatch ユーザーガイド*の「[Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/)」を参照してください。デフォルトの動作を変更して、アクションが失敗しても CloudFormation がスタックをロールバックしないようにすることもできます。ロールバックを設定するには、以下の手順に従います。 **注記** ロールバックを手動で開始することはできません。 ------ #### [ Visual ] **[開始する前に]** 1. 機能している**スタックのデプロイ CloudFormation **アクションを含む[ワークフロー](workflow.md)があることを確認します。詳細については、「[CloudFormation スタックのデプロイ](deploy-action-cfn.md)」を参照してください。 1. **スタックロール - スタックのデプロイアクションのオプション**フィールドで指定されたロールに、**CloudWatchFullAccess** アクセス許可を必ず含めてください。 ** CloudFormation **必要なアクセス許可を持つロールの作成の詳細については、「[ステップ 2: AWS ロールを作成する](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles)」を参照してください。 **CloudFormation 「スタックをデプロイ」アクションのロールバックアラームを設定するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ** CloudFormation スタックのデプロイ**アクションを選択します。 1. 詳細ペインで、**[設定]** を選択します。 1. 下部で、**[アドバンスト]** を展開します。 1. **[モニターアラーム ARN]** で、**[アラームを追加]** を選択します。 1. 次のフィールドに情報を入力します。 + **アラーム ARN** ロールバックトリガーを追加するには、Amazon CloudWatch アラームの Amazon リソースネーム (ARN) を指定します。例えば、`arn:aws:cloudwatch::123456789012:alarm/MyAlarm`。最大 5 個のロールバックトリガーを持つことができます。 **注記** CloudWatch アラーム ARN を指定する場合は、アクションが CloudWatch にアクセスできるようにする追加のアクセス許可も設定する必要があります。詳細については、「[ロールバックの設定](#deploy-consumption-enable-alarms)」を参照してください。 + **モニタリングタイム** CloudFormation が指定されたアラームをモニタリングする 0 ～ 180 分の時間を指定します。モニタリングは、すべてのスタックリソースがデプロイされた*後に*開始します。アラームが指定されたモニタリング時間内に発生した場合、デプロイは失敗し、CloudFormation はスタックオペレーション全体をロールバックします。デフォルト: 0。CloudFormation は、スタックリソースがデプロイされている間だけアラームをモニタリングします。その後はモニタリングしません。 ------ #### [ YAML ] **CloudFormation 「スタックをデプロイ」アクションのロールバックトリガーを設定するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ CloudFormation スタックをデプロイ]** アクションを含むワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ロールバックトリガーを追加するには、YAML コードに `monitor-alarm-arns` および `monitor-timeout-in-minutes` プロパティを追加します。各プロパティの説明については、「[CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)」を参照してください。 1. ** CloudFormation スタックのデプロイ**アクションの `role-arn`プロパティで指定されたロールに、**CloudWatchFullAccess** アクセス許可を必ず含めてください。必要なアクセス許可を持つロールの作成の詳細については、「[ステップ 2: AWS ロールを作成する](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles)」を参照してください。 ------ ------ #### [ Visual ] **CloudFormation 「スタックのデプロイ」アクションのロールバックを無効にするには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ CloudFormation スタックをデプロイ]** アクションを含むワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ** CloudFormation スタックのデプロイ**アクションを選択します。 1. 詳細ペインで、**[設定]** を選択します。 1. 下部で、**[アドバンスト]** を展開します。 1. **[ロールバックを無効化]** をオンにします。 ------ #### [ YAML ] **CloudFormation 「スタックのデプロイ」アクションのロールバックを無効にするには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ CloudFormation スタックをデプロイ]** アクションを含むワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ロールバックを停止するには、YAML コードに `disable-rollback: 1` プロパティを追加します。この動作の説明については、「[CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)」を参照してください。 ------ # CloudFormation 「スタックをデプロイ」変数 ** CloudFormation スタックのデプロイ**アクションは、実行時に次の変数を生成して設定します。これらは*事前定義済み変数*と呼ばれます。ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください | キー | 値 | | --- | --- | | deployment-platform | デプロイプラットフォームの名前。 `AWS:CloudFormation` にハードコードされています。 | | リージョン | ワークフローの実行中ににデプロイ AWS リージョンされたのリージョンコード。例: `us-west-2` | | stack-id | デプロイジョブの Amazon リソースネーム (ARN)。例: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cfn-stack/6aad4380-100a-11ec-a10a-03b8a84d40df` | # CloudFormation 「スタックをデプロイ」アクション YAML ** CloudFormation スタックのデプロイ**アクションの YAML 定義を次に示します。このアクションの使用方法については、「[CloudFormation スタックのデプロイ](deploy-action-cfn.md)」を参照してください。このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. DeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 DependsOn: - build-action Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Environment: Name: environment-name Connections: - Name: account-connection-name Role: DeployRole Inputs: Sources: - source-name-1 Artifacts: - CloudFormation-artifact Configuration: name: stack-name region: us-west-2 template: template-path role-arn: arn:aws:iam::123456789012:role/StackRole capabilities: CAPABILITY_IAM,CAPABILITY_NAMED_IAM,CAPABILITY_AUTO_EXPAND parameter-overrides: KeyOne=ValueOne,KeyTwo=ValueTwo | path-to-JSON-file no-execute-changeset: 1|0 fail-on-empty-changeset: 1|0 disable-rollback: 1|0 termination-protection: 1|0 timeout-in-minutes: minutes notification-arns: arn:aws:sns:us-east-1:123456789012:MyTopic,arn:aws:sns:us-east-1:123456789012:MyOtherTopic monitor-alarm-arns: arn:aws:cloudwatch::123456789012:alarm/MyAlarm,arn:aws:cloudwatch::123456789012:alarm/MyOtherAlarm monitor-timeout-in-minutes: minutes tags: '[{"Key":"MyKey1","Value":"MyValue1"},{"Key":"MyKey2","Value":"MyValue2"}]' ``` ## DeployCloudFormationStack (必須) アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。デフォルト: `DeployCloudFormationStack_nn`。対応する UI: [設定] タブ/**[アクション表示名]** ## Identifier (*DeployCloudFormationStack*/**Identifier**) (必須) アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。デフォルト: `aws/cfn-deploy@v1`。対応する UI: ワークフロー図/DeployCloudFormationStack\$1nn/**aws/cfn-deploy@v1** ラベル ## DependsOn (*DeployCloudFormationStack*/**DependsOn**) (オプション) このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。対応する UI: [入力] タブ/**[依存 - オプション]** ## Compute (*DeployCloudFormationStack*/**Compute**) (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。対応する UI: *[なし]* ## Type (*DeployCloudFormationStack*/Compute/**Type**) ([Compute](#deploy.action.cfn.computename) が含まれている場合は必須) コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。 + **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ) アクション実行時の柔軟性を目的として最適化されています。 + **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ) アクションの起動速度を最適化しました。コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングタイプ]** ## Fleet (*DeployCloudFormationStack*/Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングフリート]** ## Timeout (*DeployCloudFormationStack*/**Timeout**) (オプション) CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。対応する UI: [設定] タブ/**[分単位のタイムアウト - オプション]** ## Environment (*DeployCloudFormationStack*/**Environment**) (必須) アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウントおよびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用してに接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。 **注記** デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。環境タグ付けの詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: [設定] タブ/**[環境]** ## Name (*DeployCloudFormationStack*/Environment/**Name**) ([Environment](#deploy.action.cfn.environment) が含まれている場合は必須) アクションに関連付ける既存の環境の名前を指定します。対応する UI: [設定] タブ/**[環境]** ## Connections (*DeployCloudFormationStack*/Environment/**Connections**) (新しいバージョンのアクションでは任意。古いバージョンでは必須) アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。アカウント接続を指定しない場合: + アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 + デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Name (*DeployCloudFormationStack*/Environment/Connections/**Name**) ([Connections](#deploy.action.cfn.environment.connections) が含まれている場合は必須) アカウント接続の名前を指定します。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Role (*DeployCloudFormationStack*/Environment/Connections/**Role**) ([Connections](#deploy.action.cfn.environment.connections) が含まれている場合は必須) ** CloudFormation スタックのデプロイ**アクションが AWS および CloudFormation サービスにアクセスするために使用する IAM ロールの名前を指定します。[ロールを CodeCatalyst スペースに追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。 IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーがあることを確認してください。 + 以下のアクセス許可ポリシー: **警告** アクセス許可は、次のポリシーに示すアクセス許可に制限します。より広範なアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。 **注記** ロールを初めて使用するとき、リソースポリシーステートメントで次のワイルドカードを使用し、使用可能になった後にリソース名でポリシーをスコープダウンします。 ``` "Resource": "*" ``` + 次のカスタム信頼ポリシー: **注記** 必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]** ## Inputs (*DeployCloudFormationStack*/**Inputs**) (オプション) `Inputs` セクションでは、ワークフローの実行中に `DeployCloudFormationStack` に必要なデータを定義します。 **注記** **Deploy CloudFormation スタック**アクションごとに最大 4 つの入力 (1 つのソースと 3 つのアーティファクト) が許可されます。異なる入力 (ソースとアーティファクトなど) にあるファイルを参照する必要がある場合、ソース入力はプライマリ入力で、アーティファクトはセカンダリ入力になります。セカンダリ入力内のファイルへの参照には、プライマリからファイルを区別するための特別なプレフィックスが付きます。詳細については、「[例: 複数のアーティファクトでのファイルの参照](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)」を参照してください。対応する UI: **[入力] タブ** ## Sources (*DeployCloudFormationStack*/Inputs/**Sources**) (CloudFormation または AWS SAM テンプレートがソースリポジトリに保存されている場合は必須) CloudFormation または AWS SAM テンプレートがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。現在サポートされているラベルは、`WorkflowSource` のみです。 CloudFormation または AWS SAM テンプレートがソースリポジトリに含まれていない場合は、別のアクションによって生成されたアーティファクト、または Amazon S3 バケットに存在する必要があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。対応する UI: 入力タブ/**ソース - オプション** ## Artifacts - input (*DeployCloudFormationStack*/Inputs/**Artifacts**) (CloudFormation または AWS SAM テンプレートが前のアクションの[出力アーティファクト](workflows-working-artifacts-output.md)に保存されている場合に必要です) デプロイする CloudFormation または AWS SAM テンプレートが、前のアクションによって生成されたアーティファクトに含まれている場合は、ここでそのアーティファクトを指定します。CloudFormation テンプレートがアーティファクトに含まれていない場合は、ソースリポジトリまたは Amazon S3 バケットに存在する必要があります。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [設定] タブ/**[アーティファクト - オプション]** ## Configuration (*DeployCloudFormationStack*/**Configuration**) (必須) アクションの設定プロパティを定義できるセクション。対応する UI: **[設定]** タブ ## name (*DeployCloudFormationStack*/Configuration/**name**) (必須) **[ CloudFormation スタックをデプロイ]** アクションが作成または更新する CloudFormation スタックの名前を指定します。対応する UI: [設定] タブ/**[スタック名]** ## region (*DeployCloudFormationStack*/Configuration/**region**) (必須) スタックをデプロイする AWS リージョンを指定します。リージョンコードの一覧については、「[リージョンエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)」を参照してください。対応する UI: [設定] タブ/**[スタックリージョン]** ## template (*DeployCloudFormationStack*/Configuration/**template**) (必須) CloudFormation または AWS SAM テンプレートファイルの名前とパスを指定します。テンプレートは JSON または YAML 形式にすることができ、ソースリポジトリ、以前のアクションのアーティファクト、または Amazon S3 バケットに格納できます。テンプレートファイルがソースリポジトリまたはアーティファクトにある場合、パスはソースまたはアーティファクトルートを基準としています。テンプレートが Amazon S3 バケットにある場合、パスはテンプレートの **[オブジェクト URL]** 値です。例: `./MyFolder/MyTemplate.json` `MyFolder/MyTemplate.yml` `https://MyBucket.s3.us-west-2.amazonaws.com/MyTemplate.yml` **注記** テンプレートのファイルパスにプレフィックスを追加して、見つけるアーティファクトまたはソースを示す必要がある場合があります。詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」および「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。対応する UI: [設定] タブ/**[テンプレート]** ## role-arn (*DeployCloudFormationStack*/Configuration/**role-arn**) (必須) スタックロールの Amazon リソースネーム (ARN) を指定します。CloudFormation はこのロールを使用して、スタック内のリソースにアクセスして変更します。例: `arn:aws:iam::123456789012:role/StackRole`。スタックロールに以下が含まれていることを確認します。 + 1 つ以上のアクセス許可ポリシー。ポリシーは、スタックにあるリソースによって異なります。たとえば、スタックに AWS Lambda 関数が含まれている場合は、Lambda へのアクセスを許可するアクセス許可を追加する必要があります。[チュートリアル: サーバーレスアプリケーションをデプロイする](deploy-tut-lambda.md) で説明されているチュートリアルに従った場合、「[スタックロールを作成するには](deploy-tut-lambda.md#deploy-tut-lambda-cfn-roles-stack)」というタイトルの手順が含まれています。この手順には、一般的なサーバーレスアプリケーションスタックをデプロイする場合にスタックロールが必要とするアクセス許可が一覧表示されます。 **警告** スタック内のリソースにアクセスするために CloudFormation サービスが必要とするアクセス許可に制限します。より広範なアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。 + 次の信頼ポリシーを使用します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ 必要に応じて、このロールをアカウント接続に関連付けます。IAM ロールとアカウント接続の関連付けの詳細については、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。スタックロールをアカウント接続に関連付けない場合、スタックロールはビジュアルエディタの **[スタックロール]** ドロップダウンリストに表示されません。ただし、ロール ARN は YAML エディタを使用して `role-arn` フィールドで指定できます。 **注記** 必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。対応する UI: [設定] タブ/**[スタックロール - オプション]** ## capabilities (*DeployCloudFormationStack*/Configuration/**capabilities**) (必須) が特定のスタック CloudFormation を作成するために必要な IAM 機能のリストを指定します。ほとんどの場合、`CAPABILITY_IAM,CAPABILITY_NAMED_IAM,CAPABILITY_AUTO_EXPAND` のデフォルト値は `capabilities` のままにすることができます。 **[ CloudFormation スタックをデプロイ]** アクションのログに `##[error] requires capabilities: [capability-name]` が表示された場合は、「[IAM 機能エラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-capabilities)」を参照して問題を解決する方法を確認してください。 IAM 機能の詳細については、[「IAM ユーザーガイド」の CloudFormation 「テンプレートでの IAM リソースの承認](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html#using-iam-capabilities)」を参照してください。 ** 対応する UI: [設定] タブ/アドバンスト/**[機能]** ## parameter-overrides (*DeployCloudFormationStack*/Configuration/**parameter-overrides**) (オプション) デフォルト値を持たない CloudFormation 、またはデフォルト値以外の値を指定するパラメータをまたは AWS SAM テンプレートで指定します。パラメータの詳細については、 * AWS CloudFormation ユーザーガイド*の[「パラメータ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html)」を参照してください。 `parameter-overrides` プロパティは以下を受け入れます。 + パラメータと値を含む JSON ファイル。 + パラメータと値のカンマ区切りリスト。 **JSON ファイルを指定するには** 1. JSON ファイルで次のいずれかの構文を使用していることを確認します。 ``` { "Parameters": { "Param1": "Value1", "Param2": "Value2", ... } } ``` または… ``` [ { "ParameterKey": "Param1", "ParameterValue": "Value1" }, ... ] ``` (他の構文もありますが、記述時に CodeCatalyst ではサポートされていません。) JSON ファイルで CloudFormation パラメータを指定する方法の詳細については、「*AWS CLI コマンドリファレンス*」の「[サポートされている JSON 構文](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudformation/deploy/index.html#supported-json-syntax)」を参照してください。 1. 次のいずれかの形式を使用して、JSON ファイルへのパスを指定します。 + JSON ファイルが前のアクションの出力アーティファクトに存在する場合は、以下を使用します。 `file:///artifacts/current-action-name/output-artifact-name/path-to-json-file` 詳細については、「**例 1**」を参照してください。 + JSON ファイルがソースリポジトリにある場合は、以下を使用します。 `file:///sources/WorkflowSource/path-to-json-file` 詳細については、「**例 2**」を参照してください。 **例 1** – JSON ファイルは出力アーティファクトにあります ``` ##My workflow YAML ... Actions: MyBuildAction: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ParamArtifact Files: - params.json Configuration: ... MyDeployCFNStackAction: Identifier: aws/cfn-deploy@v1 Configuration: parameter-overrides: file:///artifacts/MyDeployCFNStackAction/ParamArtifact/params.json ``` **例 2** – JSON ファイルは、ソースリポジトリの「`my/folder`」という名前のフォルダにあります。 ``` ##My workflow YAML ... Actions: MyDeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 Inputs: Sources: - WorkflowSource Configuration: parameter-overrides: file:///sources/WorkflowSource/my/folder/params.json ``` **パラメータのカンマ区切りリストを使用するには** + 次の形式を使用して、`parameter-overrides` プロパティにパラメータ名と値のペアを追加します。 `param-1=value-1,param-2=value-2` たとえば、次の CloudFormation テンプレートがあるとします。 ``` ##My CloudFormation template Description: My CloudFormation template Parameters: InstanceType: Description: Defines the Amazon EC2 compute for the production server. Type: String Default: t2.micro AllowedValues: - t2.micro - t2.small - t3.medium Resources: ... ``` ...`parameter-overrides` プロパティは次のように設定できます。 ``` ##My workflow YAML ... Actions: ... DeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 Configuration: parameter-overrides: InstanceType=t3.medium,UseVPC=true ``` **注記** パラメータ名は、`undefined` を値として使用して、対応する値なしで指定できます。例えば、次のようになります。 `parameter-overrides: MyParameter=undefined` スタックの更新中に、CloudFormation は指定されたパラメータ名に既存のパラメータ値を使用するという効果があります。対応する UI: + [設定] タブ/アドバンスト/**[パラメータのオーバーライド]** + ファイルを使用して[設定] タブ/アドバンスト/パラメータオーバーライド/**[オーバーライドを指定]** + 値セットを使用して[設定] タブ/アドバンスト/パラメータオーバーライド/**値セットを使用してオーバーライドを指定** ## no-execute-changeset (*DeployCloudFormationStack*/Configuration/**no-execute-changeset**) (オプション) CodeCatalyst で CloudFormation 変更セットを作成し、実行する前に停止するかどうかを指定します。これにより、CloudFormation コンソールで変更セットを確認できます。変更セットが正常に見える場合は、このオプションを無効にしてからワークフローを再実行し、CodeCatalyst が停止することなく変更セットを作成および実行できるようにします。デフォルトでは、停止せずに変更セットを作成して実行します。詳細については、*AWS CLI 「コマンドリファレンス」の* CloudFormation [「deploy](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) パラメータ」を参照してください。変更セットの表示の詳細については、「*AWS CloudFormation ユーザーガイド*」の「[変更セットの表示](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-view.html)」を参照してください。対応する UI: [設定] タブ/詳細/**[実行なしの変更セット]** ## fail-on-empty-changeset (*DeployCloudFormationStack*/Configuration/**fail-on-empty-changeset**) (オプション) CloudFormation 変更セットが空の場合、CodeCatalyst が** CloudFormation スタックのデプロイ**アクションを失敗させるかどうかを指定します。(変更セットが空の場合、最新のデプロイ中にスタックに変更が行われなかったことを意味します。) デフォルトでは、変更セットが空の場合にアクションを続行し、スタックが更新されていなくても `UPDATE_COMPLETE` メッセージを返すことを許可します。この設定の詳細については、*AWS CLI 「コマンドリファレンス*」の CloudFormation [「deploy](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) パラメータ」を参照してください。変更セットの詳細については、「*AWS CloudFormation ユーザーガイド*」の「[変更セットを使用したスタックの更新](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html)」を参照してください。対応する UI: [設定] タブ/アドバンスト/**[空の変更セットで失敗]** ## disable-rollback (*DeployCloudFormationStack*/Configuration/**disable-rollback**) (オプション) CodeCatalyst がスタックデプロイに失敗した場合にロールバックするかどうかを指定します。ロールバックは、スタックを最後に既知の安定状態に戻します。デフォルトでは、ロールバックを有効にします。この設定の詳細については、*AWS CLI 「コマンドリファレンス*」の CloudFormation [「deploy](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) パラメータ」を参照してください。 ** CloudFormation スタックのデプロイ**アクションがロールバックを処理する方法の詳細については、「」を参照してください[ロールバックの設定](deploy-consumption-enable-alarms.md)。スタックのロールバックの詳細については、*「AWS CloudFormation ユーザーガイド*」の「[スタック失敗オプション](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stack-failure-options.html)」を参照してください。対応する UI: [設定] タブ/アドバンスト/**[ロールバックを無効化]** ## termination-protection (*DeployCloudFormationStack*/Configuration/**termination-protection**) (オプション) **Deploy CloudFormation スタック**で、デプロイするスタックに終了保護を追加するかどうかを指定します。削除保護を有効にした状態でスタックを削除しようとすると、削除は失敗し、ステータスを含め、スタックが変更されることはありません。終了保護はデフォルトで無効になっています。詳細については、「*AWS CloudFormation ユーザーガイド*」の「[スタックが削除されないように保護する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-protect-stacks.html)」を参照してください。対応する UI: [設定] タブ/アドバンスト/**[終了保護]** ## timeout-in-minutes (*DeployCloudFormationStack*/Configuration/**timeout-in-minutes**) (オプション) CloudFormation がスタック作成オペレーションのタイムアウトまでに割り当て、スタックのステータスを `CREATE_FAILED` に設定する時間を分で指定します。CloudFormation が割り当てられた時間内にスタック全体を作成できない場合、スタックの作成がタイムアウトで失敗し、スタックはロールバックされます。デフォルトでは、スタックの作成にタイムアウトはありません。ただし、個々のリソースには、実装するサービスの性質に基づいて、独自のタイムアウトがある可能性があります。例えば、スタック内の個々のリソースがタイムアウトになった場合、スタックの作成に指定されたタイムアウトに到達していない場合でも、スタックの作成もタイムアウトになります。対応する UI: [設定] タブ/アドバンスト/**[CloudFormation タイムアウト]** ## notification-arns (*DeployCloudFormationStack*/Configuration/**notification-arns**) (オプション) CodeCatalyst が通知メッセージを送信する Amazon SNS トピックの ARN を指定します。例えば、`arn:aws:sns:us-east-1:111222333:MyTopic`。** CloudFormation スタックのデプロイ**アクションが実行されると、CodeCatalyst は CloudFormation と連携して、スタックの作成または更新プロセス中に発生する CloudFormation イベントごとに 1 つの通知を送信します。(イベントは、スタックの CloudFormation コンソールの**イベント**タブに表示されます）。最大 5 つのトピックを追加できます。詳細については、「[Amazon SNS とは](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」を参照してください。対応する UI: [設定] タブ/アドバンスト/**[通知 ARN]** ## monitor-alarm-arns (*DeployCloudFormationStack*/Configuration/**monitor-alarm-arns**) (オプション) ロールバックトリガーを追加するには、Amazon CloudWatch アラームの Amazon リソースネーム (ARN) を指定します。例えば、`arn:aws:cloudwatch::123456789012:alarm/MyAlarm`。最大 5 個のロールバックトリガーを持つことができます。 **注記** CloudWatch アラーム ARN を指定する場合は、アクションが CloudWatch にアクセスできるようにする追加のアクセス許可も設定する必要があります。詳細については、「[ロールバックの設定](deploy-consumption-enable-alarms.md)」を参照してください。対応する UI: [設定] タブ/アドバンスト/**[モニターアラーム ARN]** ## monitor-timeout-in-minutes (*DeployCloudFormationStack*/Configuration/**monitor-timeout-in-minutes**) (オプション) CloudFormation が指定されたアラームをモニタリングする 0 ～ 180 分の時間を指定します。モニタリングは、すべてのスタックリソースがデプロイされた*後に*開始します。アラームが指定されたモニタリング時間内に発生した場合、デプロイは失敗し、CloudFormation はスタックオペレーション全体をロールバックします。デフォルト: 0。CloudFormation は、スタックリソースがデプロイされている間だけアラームをモニタリングします。その後はモニタリングしません。対応する UI: [設定] タブ/アドバンスト/**[モニタリング時間]** ## tags (*DeployCloudFormationStack*/Configuration/**tags**) (オプション) CloudFormation スタックにアタッチするタグを指定します。タグは、コスト配分など、スタックを識別する目的で使用できる任意のキーと値のペアです。タグとその使用方法の詳細については、「Amazon EC2 ユーザーガイド」の「[リソースのタグ付け](https://docs.aws.amazon.com/)」を参照してください。CloudFormation でのタグ付けの詳細については、*AWS CloudFormation 「ユーザーガイド*」の[CloudFormation 「スタックオプションの設定](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-add-tags.html)」を参照してください。キーには英数字またはスペースを含めることができ、最大 127 文字を使用できます。値には英数字またはスペースを含めることができ、最大 255 文字を使用できます。スタックごとに最大 50 個の一意のタグを追加できます。対応する UI: [設定] タブ/アドバンスト/**[タグ]** # ワークフローを使用した AWS CDK アプリケーションのデプロイこのセクションでは、ワークフローを使用して AWS Cloud Development Kit (AWS CDK) アプリを AWS アカウントにデプロイする方法について説明します。これを行うには、**[AWS CDK デプロイ]** アクションをワークフローに追加する必要があります。**AWS CDK デプロイ**アクションは、アプリケーションを合成してデプロイします AWS Cloud Development Kit (AWS CDK) AWS。アプリがにすでに存在する場合 AWS、アクションは必要に応じてアプリを更新します。を使用したアプリの記述に関する一般的な情報については AWS CDK、[「とは」を参照してください AWS CDK。](https://docs.aws.amazon.com/cdk/v2/guide/home.html) *AWS Cloud Development Kit (AWS CDK) 「デベロッパーガイド*」の「� **Topics** + [ ## AWS CDK 「デプロイ」アクションを使用するタイミング ](#cdk-dep-action-when-to-use) + [ ## AWS CDK 「デプロイ」アクションの仕組み ](#cdk-dep-action-how-it-works) + [ ## AWS CDK 「デプロイ」アクションで使用される CDK CLI バージョン ](#cdk-dep-action-cdk-version) + [ ## AWS CDK 「デプロイ」アクションで使用されるランタイムイメージ ](#cdk-dep-action-runtime) + [ ## アクションはいくつのスタックをデプロイできますか? ](#cdk-dep-action-how-many-stacks) + [ # 例: AWS CDK アプリケーションのデプロイ ](cdk-dep-action-example-workflow.md) + [ # AWS CDK 「デプロイ」アクションの追加 ](cdk-dep-action-add.md) + [ # 「AWS CDK デプロイ」変数 ](cdk-dep-action-variables.md) + [ # 「AWS CDK デプロイ」アクション YAML ](cdk-dep-action-ref.md) ## AWS CDK 「デプロイ」アクションを使用するタイミングを使用してアプリケーションを開発し AWS CDK、自動継続的インテグレーションと配信 (CI/CD) ワークフローの一部として自動的にデプロイする場合は、このアクションを使用します。たとえば、誰かが AWS CDK アプリソースに関連するプルリクエストをマージするたびに、 AWS CDK アプリを自動的にデプロイできます。 ## AWS CDK 「デプロイ」アクションの仕組み「**AWS CDK デプロイ**」は次のように機能します。 1. 実行時に、アクションのバージョン 1.0.12 以前を指定した場合、アクションは最新の CDK CLI (Tookit とも呼ばれます) AWS CDK を CodeCatalyst [ランタイム環境イメージ](#cdk-dep-action-runtime)にダウンロードします。バージョン 1.0.13 以降を指定した場合、アクションは [特定のバージョン](#cdk-dep-action-cdk-version) の CDK CLI にバンドルされるため、ダウンロードは行われません。 1. アクションは CDK CLI を使用して `cdk deploy` コマンドを実行します。このコマンドは、 AWS CDK アプリケーションを合成してデプロイします AWS。このコマンドの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[AWS CDK ツールキット (cdk コマンド)](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html)」を参照してください。 ## AWS CDK 「デプロイ」アクションで使用される CDK CLI バージョン次の表は、**[AWS CDK デプロイ]** アクションのさまざまなバージョンでデフォルトで使用されている CDK CLI のバージョンを示しています。 **注記** デフォルトを上書きできる場合があります。詳細については、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」の「[CdkCliVersion](cdk-dep-action-ref.md#cdk.dep.cdk.cli.version)」を参照してください。 | 「AWS CDK デプロイ」アクションバージョン | AWS CDK CLI バージョン | | --- | --- | | 1.0.0～1.0.12 | 最新 | | 1.10.13 以降 | 2.99.1 | ## AWS CDK 「デプロイ」アクションで使用されるランタイムイメージ次の表は、CodeCatalyst が **[AWS CDK デプロイ]** アクションのさまざまなバージョンを実行するために使用するランタイム環境イメージを示しています。イメージには、プリインストールされたさまざまなツールのセットが含まれています。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。 **注記** 2024 年 3 月のイメージで利用可能な最新のツールを利用するには、**[AWS CDK デプロイ]** アクションをバージョン 2.x にアップグレードすることをお勧めします。アクションをアップグレードするには、ワークフロー定義ファイルの `Identifier` プロパティを `aws/cdk-deploy@v2` に設定します。詳細については、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」を参照してください。 | 「AWS CDK デプロイ」アクションバージョン | ランタイム環境イメージ | | --- | --- | | 1.x | 2022 年 11 月のイメージ | | 2.x | 2024 年 3 月のイメージ | ## アクションはいくつのスタックをデプロイできますか? **[AWS CDK デプロイ]** は 1 つのスタックのみをデプロイできます。 AWS CDK アプリが複数のスタックで構成されている場合は、ネストされたスタックを持つ親スタックを作成し、このアクションを使用して親をデプロイする必要があります。 # 例: AWS CDK アプリケーションのデプロイ次のワークフローの例には、**[AWS CDK デプロイ]** アクションと **[AWS CDK ブートストラップ]** アクションが含まれています。ワークフローは、連続して実行される次の構成要素で構成されます。 + **トリガー** – ソースリポジトリに変更をプッシュすると、このトリガーによってワークフローが自動的に開始されます。このリポジトリには AWS CDK アプリが含まれています。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + **AWS CDK ブートストラップ**アクション (`CDKBootstrap`) – トリガー時に、アクションは`CDKToolkit`ブートストラップスタックをにデプロイします AWS。`CDKToolkit` スタックが環境内に既に存在する場合、必要に応じてアップグレードされます。それ以外の場合、何も発生せず、アクションは成功としてマークされます。 + **AWS CDK デプロイ**アクション (`AWS CDK Deploy`) – **AWS CDK ブートストラップ**アクションが完了すると、**AWS CDK デプロイ**アクションは AWS CDK アプリケーションコードを CloudFormation テンプレートに合成し、テンプレートで定義されたスタックをにデプロイします AWS。 **注記** 次のワークフロー例は説明を目的としており、追加の設定なしでは機能しません。 **注記** 次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。これらのセクションを省略する場合は、環境の **[デフォルト IAM ロールフィールドで指定されたロール]** に、**[AWS CDK ブートストラップ]** アクションと **[AWS CDK デプロイ]** アクションに必要なアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。**[AWS CDK ブートストラップ]** アクションと **[AWS CDK デプロイ]** アクションに必要なアクセス許可と信頼ポリシーの詳細については、 [「AWS CDK ブートストラップ」アクション YAML](cdk-boot-action-ref.md) および [「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md) の `Role` プロパティの説明を参照してください。 ``` Name: codecatalyst-cdk-deploy-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: CDKBootstrap: Identifier: aws/cdk-bootstrap@v2 Inputs: Sources: - WorkflowSource Environment: Name: codecatalyst-cdk-deploy-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-cdk-bootstrap-role Configuration: Region: us-west-2 CDKDeploy: Identifier: aws/cdk-deploy@v2 DependsOn: - CDKBootstrap Environment: Name: codecatalyst-cdk-deploy-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-cdk-deploy-role Inputs: Sources: - WorkflowSource Configuration: StackName: my-app-stack Region: us-west-2 ``` # AWS CDK 「デプロイ」アクションの追加次の手順を使用して、**[AWS CDK デプロイ]** アクションをワークフローに追加します。 **[開始する前に]** ワークフローに **[AWS CDK デプロイ]** アクションを追加する前に、次のタスクを完了します。 1. ** AWS CDK アプリの準備をします**。v1 または AWS CDK v2 を使用して、でサポートされている任意のプログラミング言語で AWS CDK アプリを記述できます AWS CDK。 AWS CDK アプリファイルが次の場所で利用可能であることを確認します。 + CodeCatalyst [[ソースリポジトリ]](source.md)、または + 別のワークフローアクションによって生成された CodeCatalyst [出力アーティファクト](workflows-working-artifacts.md) 1. ** AWS 環境をブートストラップします**。ブートストラップするには、次の操作を行います。 + 「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[ブートストラップをする方法](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-howto)」で説明されている方法のいずれかを使用します。 + **[AWS CDK ブートストラップ]** アクションを使用します。このアクションは、**[AWS CDK デプロイ]** と同じワークフロー、または別のワークフローに追加できます。必要なリソースが配置されるように、**[AWS CDK デプロイ]** アクションを実行する前に、ブートストラップアクションが少なくとも 1 回実行されていることを確認してください。**AWS CDK ブートストラップアクションの詳細については、**「」を参照してください[ワークフローを使用して AWS CDK アプリをブートストラップする](cdk-boot-action.md)。ジョブのブックマークの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[ジョブブックマーク](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)」を参照してください。 ------ #### [ Visual ] **ビジュアルエディタを使用してAWS CDK 「デプロイ」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[AWS CDK デプロイ]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[AWS CDK デプロイ]** を選択します。[アクションの詳細] ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。 + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 **注記** **[AWS CDK デプロイ]** アクションが `npm install` エラーで失敗した場合、エラーを修正する方法については、「[「npm install」エラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-npm)」を参照してください。 ------ #### [ YAML ] **YAML エディタを使用してAWS CDK 「デプロイ」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[AWS CDK デプロイ]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[AWS CDK デプロイ]** を選択します。[アクションの詳細] ダイアログボックスが表示されます。このダイアログボックスでは、次の操作を行います。 + (オプション) **[ダウンロード]** を選択して、[アクションのソースコードを表示](workflows-view-source.md#workflows-view-source.title)します。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」に記載されています。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 **注記** **[AWS CDK デプロイ]** アクションが `npm install` エラーで失敗した場合、エラーを修正する方法については、「[「npm install」エラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-npm)」を参照してください。 ------ # 「AWS CDK デプロイ」変数 **[AWS CDK デプロイ]** アクションは、実行時に次の変数を生成して設定します。これらは*事前定義済み変数*と呼ばれます。ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください | キー | 値 | | --- | --- | | stack-id | ワークフローの実行中ににデプロイされた AWS CDK アプリケーションスタックの Amazon リソースネーム (ARN)。例: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cdk-app-stack/6aad4380-100a-11ec-a10a-03b8a84d40df` | | deployment-platform | デプロイプラットフォームの名前。 `AWS:CloudFormation` にハードコードされています。 | | リージョン | ワークフローの実行中ににデプロイ AWS リージョンされたのリージョンコード。例: `us-west-2` | | SKIP-DEPLOYMENT | の値は、ワークフローの実行中に AWS CDK アプリケーションスタックのデプロイがスキップされた`true`ことを示します。前回のデプロイ以降にスタックに変更がない場合、スタックのデプロイはスキップされます。この変数は、値が `true` の場合にのみ生成されます。 `true` にハードコードされています。 | | *CloudFormation variables* | 前述の変数を生成するだけでなく、**[AWS CDK デプロイ]** アクションでは、*[CloudFormation]* 出力変数を後続の *[ワークフロー]* アクションで使用するワークフロー変数として公開します。デフォルトでは、このアクションは検出した最初の 4 つ (またはそれ以下の) CloudFormation 変数のみを公開します。どのアクションが公開されているかを確認するには、**[AWS CDK デプロイ]** アクションを 1 回実行し、実行の詳細ページの **[変数]** タブを確認します。**[変数]** タブに一覧表示されている変数が目的の変数でない場合は、YAML `CfnOutputVariables` プロパティを使用して異なる変数を設定できます。詳細については、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」の「[CfnOutputVariables](cdk-dep-action-ref.md#cdk.dep.cfn.out) プロパティの説明」をご参照ください。 | # 「AWS CDK デプロイ」アクション YAML **[AWS CDK デプロイ]** アクションの YAML 定義を次に示します。このアクションの使用方法については、「[ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)」を参照してください。このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. CDKDeploy\$1nn: Identifier: aws/cdk-deploy@v2 DependsOn: - CDKBootstrap Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - artifact-name Outputs: Artifacts: - Name: cdk_artifact Files: - "cdk.out/**/*" Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Configuration: StackName: my-cdk-stack Region: us-west-2 Tags: '{"key1": "value1", "key2": "value2"}' Context: '{"key1": "value1", "key2": "value2"}' CdkCliVersion: version CdkRootPath: directory-containing-cdk.json-file CfnOutputVariables: '["CnfOutputKey1","CfnOutputKey2","CfnOutputKey3"]' CloudAssemblyRootPath: path-to-cdk.out ``` ## CDKDeploy (必須) アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。デフォルト: `CDKDeploy_nn`。対応する UI: [設定] タブ/**[アクション名]** ## Identifier (*CDKDeploy*/**Identifier**) (必須) アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。 **注記** `aws/cdk-deploy@v2` を指定すると、Node.js 18 などの新しいツールを含む [2024 年](build-images.md#build.default-image) 3 月の画像でアクションが実行されます。`aws/cdk-deploy@v1` を指定すると、Node.js 16 などの古いツールを含む [2022 年 11 月のイメージ](build-images.md#build.previous-image)でアクションが実行されます。デフォルト: `aws/cdk-deploy@v2`。対応する UI: ワークフロー図/CDKDeploy\$1nn/**aws/cdk-deploy@v2** ラベル ## DependsOn (*CDKDeploy*/**DependsOn**) (オプション) このアクションを実行するために正常に実行する必要があるアクション、アクショングループを指定します。次のような **[AWS CDK ブートストラップ]** アクションを `DependsOn` プロパティで指定することをお勧めします。 ``` CDKDeploy: Identifier: aws/cdk-deploy@v2 DependsOn: - CDKBootstrap ``` **注記** [ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)は、 AWS CDK アプリケーションをデプロイするための必須の前提条件です。ワークフローに **[AWS CDK ブートストラップ]**アクションを含めない場合は、[AWS CDK デプロイアクション] を実行する前に、 AWS CDK ブートストラップスタックをデプロイする別の方法を見つける必要があります。詳細については、「[ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)」の [AWS CDK 「デプロイ」アクションの追加](cdk-dep-action-add.md) を参照してください。「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。対応する UI: [入力] タブ/**[依存 - オプション]** ## Compute (*CDKDeploy*/**Compute**) (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。対応する UI: *[なし]* ## Type (*CDKDeploy*/Compute/**Type**) ([Compute](#cdk.dep.computename) が含まれている場合は必須) コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。 + **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ) アクション実行時の柔軟性を目的として最適化されています。 + **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ) アクションの起動速度を最適化しました。コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングタイプ]** ## Fleet (*CDKDeploy*/Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングフリート]** ## Timeout (*CDKDeploy*/**Timeout**) (必須) CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。対応する UI: [設定] タブ/**[タイムアウト - オプション]** ## Inputs (*CDKDeploy*/**Inputs**) (オプション) `Inputs` セクションでは、ワークフローの実行中に `CDKDeploy` に必要なデータを定義します。 **注記** **[AWS CDK デプロイ]** アクションごとに 1 つの入力 (ソースまたはアーティファクト) のみが許可されます。対応する UI: **[入力]** タブ ## Sources (*CDKDeploy*/Inputs/**Sources**) (デプロイする AWS CDK アプリがソースリポジトリに保存されている場合に必須) AWS CDK アプリがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。**[AWS CDK デプロイ]** アクションは、デプロイプロセスを開始する前に、このリポジトリ内のアプリケーションを合成します。現在サポートされているラベルは、`WorkflowSource` のみです。 AWS CDK アプリがソースリポジトリに含まれていない場合は、別のアクションによって生成されたアーティファクトに存在する必要があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。対応する UI: 入力タブ/**ソース - オプション** ## Artifacts - input (*CDKDeploy*/Inputs/**Artifacts**) (デプロイする AWS CDK アプリケーションが前のアクションの[出力アーティファクト](workflows-working-artifacts-output.md)に保存されている場合に必須) 前のアクションによって生成されたアーティファクトに AWS CDK アプリが含まれている場合は、ここでそのアーティファクトを指定します。**[AWS CDK デプロイ]** アクションは、デプロイプロセスを開始する前に、指定されたアーティファクト内のアプリケーションを CloudFormation テンプレートに合成します。 AWS CDK アプリがアーティファクトに含まれていない場合は、ソースリポジトリに存在する必要があります。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: 入力タブ/**アーティファクト - オプション** ## Outputs (*CDKDeploy*/**Outputs**) (オプション) ワークフローの実行中にアクションによって出力されるデータを定義します。対応する UI: **[出力]** タブ ## Artifacts - output (*CDKDeploy*/Outputs/**Artifacts** (オプション) アクションによって生成されたアーティファクトを指定します。このアーティファクトは、他のアクションの入力として参照できます。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [出力] タブ/**[アーティファクト]** ## Name (*CDKDeploy*/Outputs/Artifacts/**Name**) ([Artifacts - output](#cdk.dep.outputs.artifacts) が含まれている場合は必須) 実行時に**AWS CDK デプロイ**アクションによって合成される CloudFormation テンプレートを含むアーティファクトの名前を指定します。デフォルト値は `cdk_artifact` です。アーティファクトを指定しない場合、アクションはテンプレートを合成しますが、アーティファクトには保存されません。テストまたはトラブルシューティングの目的で、合成されたテンプレートをアーティファクトに保存して、その記録を保持することを検討してください。対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドアーティファクト名]** ## Files (*CDKDeploy*/Outputs/Artifacts/**Files**) ([Artifacts - output](#cdk.dep.outputs.artifacts) が含まれている場合は必須) アーティファクトに含めるファイルを指定します。 AWS CDK アプリの合成された CloudFormation テンプレートを含める`"cdk.out/**/*"`には、を指定する必要があります。 **注記** `cdk.out` は、合成されたファイルが保存されるデフォルトのディレクトリです。`cdk.json` ファイルで `cdk.out` 以外の出力ディレクトリを指定した場合は、`cdk.out` の代わりに、ここでそのディレクトリを指定します。対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドで生成されるファイル]** ## Environment (*CDKDeploy*/**Environment**) (必須) アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウントおよびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用してに接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。 **注記** デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。環境タグ付けの詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: [設定] タブ/**[環境]** ## Name (*CDKDeploy*/Environment/**Name**) ([Environment](#cdk.dep.environment) が含まれている場合は必須) アクションに関連付ける既存の環境の名前を指定します。対応する UI: [設定] タブ/**[環境]** ## Connections (*CDKDeploy*/Environment/**Connections**) (新しいバージョンのアクションでは任意。古いバージョンでは必須) アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。アカウント接続を指定しない場合: + アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 + デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Name (*CDKDeploy*/Environment/Connections/**Name**) ([Connections](#cdk.dep.environment.connections) が含まれている場合は必須) アカウント接続の名前を指定します。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Role (*CDKDeploy*/Environment/Connections/**Role**) ([Connections](#cdk.dep.environment.connections) が含まれている場合は必須) アカウント接続の名前を指定します。 **AWS CDK デプロイ**アクションが AWS CDK アプリケーションスタックにアクセスして AWS デプロイするために使用する IAM ロールの名前を指定します。[ロールを CodeCatalyst スペースに追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。 IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーがあることを確認してください。 + 以下のアクセス許可ポリシー: **警告** アクセス許可は、次のポリシーに示すアクセス許可に制限します。範囲の広いアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "cloudformation:DescribeStackEvents", "cloudformation:DescribeChangeSet", "cloudformation:DescribeStacks", "cloudformation:ListStackResources" ], "Resource": "*" }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/cdk-*" } ] } ``` ------ + 次のカスタム信頼ポリシー: **注記** 必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]** ## Configuration (*CDKDeploy*/**Configuration**) (必須) アクションの設定プロパティを定義できるセクション。対応する UI: **[設定]** タブ ## StackName (*CDKDeploy*/Configuration/**StackName**) (必須) AWS CDK アプリの `bin` ディレクトリのエントリポイントファイルに表示される AWS CDK アプリスタックの名前。次の例は、TypeScript エントリポイントファイルの内容を示し、スタック名は*赤い斜体*で強調表示されています。エントリポイントファイルが別の言語の場合、似ています。 ``` import * as cdk from 'aws-cdk-lib'; import { CdkWorksopTypescriptStack } from '../lib/cdk_workshop_typescript-stack'; const app = new cdk.App(); new CdkWorkshopTypescriptStack(app, 'CdkWorkshopTypescriptStack'); ``` 指定できるスタックは 1 つだけです。 **ヒント** 複数のスタックがある場合は、ネストされたスタックを使用して親スタックを作成できます。その後、このアクションで親スタックを指定して、すべてのスタックをデプロイできます。対応する UI: [設定] タブ/**[スタック名]** ## Region (*CDKDeploy*/Configuration/**Region**) (オプション) AWS CDK アプリケーションスタックをデプロイする AWS リージョンを指定します。リージョンコードの一覧については、「[リージョンエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)」を参照してください。リージョンを指定しない場合、**AWS CDK デプロイ**アクションは AWS CDK コードで指定されたリージョンにデプロイされます。詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[環境枠](https://docs.aws.amazon.com/cdk/v2/guide/environments.html)」を参照してください。対応する UI: [設定] タブ/**[リージョン]** ## Tags (*CDKDeploy*/Configuration/**Tags**) (オプション) AWS CDK アプリケーションスタックの AWS リソースに適用するタグを指定します。タグは、スタック自体とスタック内の個々のリソースに適用されます。タグ付けの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[タグ付け](https://docs.aws.amazon.com/cdk/v2/guide/tagging.html)」を参照してください。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[タグ]** ## Context (*CDKDeploy*/Configuration/**Context**) (オプション) AWS CDK アプリケーションスタックに関連付けるコンテキストをキーと値のペアの形式で指定します。コンテキストの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[ランタイムコンテキスト](https://docs.aws.amazon.com/cdk/v2/guide/context.html)」を参照してください。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンテキスト]** ## CdkCliVersion (*CDKDeploy*/Configuration/**CdkCliVersion**) (オプション) このプロパティは、**[AWS CDK デプロイ]** アクションのバージョン 1.0.13 以降、および **[AWS CDK ブートストラップ]** アクションのバージョン 1.0.8 以降で使用できます。次のいずれかを指定します。 + このアクションで使用する AWS Cloud Development Kit (AWS CDK) コマンドラインインターフェイス (CLI) のフルバージョン (ツールキットとも呼ばれ AWS CDK ます）。例えば、`2.102.1` などです。アプリケーションのビルドとデプロイ時に一貫性と安定性を確保するため、フルバージョンを指定することを検討してください。または + `latest`。CDK CLI の最新の機能と修正を活用するには、`latest` を指定することを検討してください。アクションは、指定されたバージョンの CLI (または最新バージョン) AWS CDK を CodeCatalyst [ビルドイメージ](build-images.md)にダウンロードし、このバージョンを使用して CDK アプリケーションのデプロイまたは環境のブートストラップ AWS に必要なコマンドを実行します。使用できるサポートされている CDK CLI バージョンの一覧については、[[AWS CDK バージョン]](https://docs.aws.amazon.com/cdk/api/versions.html) を参照してください。このプロパティを省略すると、アクションは次のいずれかのトピックで説明されているデフォルトの AWS CDK CLI バージョンを使用します。 + [AWS CDK 「デプロイ」アクションで使用される CDK CLI バージョン](cdk-dep-action.md#cdk-dep-action-cdk-version) + [AWS CDK 「ブートストラップ」アクションで使用される CDK CLI バージョン](cdk-boot-action.md#cdk-boot-action-cdk-version) 対応する UI: 設定タブ/**AWS CDK CLI バージョン** ## CdkRootPath (*CDKDeploy*/Configuration/**CdkRootPath**) (オプション) AWS CDK プロジェクトの `cdk.json` ファイルを含むディレクトリへのパス。**[AWS CDK デプロイ]** アクションはこのフォルダから実行され、アクションによって作成された出力はこのディレクトリに追加されます。指定しない場合、**AWS CDK デプロイ**アクションは`cdk.json`ファイルが AWS CDK プロジェクトのルートにあることを前提としています。対応する UI: [設定] タブ/**cdk.json が存在するディレクトリ** ## CfnOutputVariables (*CDKDeploy*/Configuration/**CfnOutputVariables**) (オプション) ワークフロー出力変数として公開する AWS CDK アプリケーションコード内の`CfnOutput`コンストラクトを指定します。その後、ワークフロー内の後続のアクションでワークフロー出力変数を参照できます。CodeCatalyst における変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。たとえば、 AWS CDK アプリケーションコードは次のようになります。 ``` import { Duration, Stack, StackProps, CfnOutput, RemovalPolicy} from 'aws-cdk-lib'; import * as dynamodb from 'aws-cdk-lib/aws-dynamodb'; import * as s3 from 'aws-cdk-lib/aws-s3'; import { Construct } from 'constructs'; import * as cdk from 'aws-cdk-lib'; export class HelloCdkStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', { removalPolicy: RemovalPolicy.DESTROY, }); new CfnOutput(this, 'bucketName', { value: bucket.bucketName, description: 'The name of the s3 bucket', exportName: 'amzn-s3-demo-bucket', }); const table = new dynamodb.Table(this, 'todos-table', { partitionKey: {name: 'todoId', type: dynamodb.AttributeType.NUMBER}, billingMode: dynamodb.BillingMode.PAY_PER_REQUEST, removalPolicy: RemovalPolicy.DESTROY, }) new CfnOutput(this, 'tableName', { value: table.tableName, description: 'The name of the dynamodb table', exportName: 'myDynamoDbTable', }); ... } } ``` ...`CfnOutputVariables` プロパティは次のようになります。 ``` Configuration: ... CfnOutputVariables: '["bucketName","tableName"]' ``` ...その後、アクションは次のワークフロー出力変数を生成します。 | キー | 値 | | --- | --- | | bucketName | `bucket.bucketName` | | tableName | `table.tableName` | その後、後続のアクションで `bucketName` 変数と `tableName` 変数を参照できます。後続のアクションでワークフロー出力変数を参照する方法については、「[事前定義済み変数の参照](workflows-working-with-variables-reference-output-vars.md)」を参照してください。 `CfnOutputVariables` プロパティに `CfnOutput` コンストラクトを指定しない場合、アクションはワークフロー出力変数として検出される最初の 4 つ (またはそれ以下) の CloudFormation 出力変数を公開します。詳細については、「[「AWS CDK デプロイ」変数](cdk-dep-action-variables.md)」を参照してください。 **ヒント** アクションが生成するすべての CloudFormation 出力変数の一覧を取得するには、**[AWS CDK デプロイ]** アクションを含むワークフローを 1 回実行し、アクションの **[ログ]** タブを確認します。ログには、 AWS CDK アプリに関連付けられているすべての CloudFormation 出力変数のリストが含まれます。すべての CloudFormation 変数が何であるかがわかったら、`CfnOutputVariables` プロパティを使用してワークフロー出力変数に変換する変数を指定できます。 CloudFormation 出力変数の詳細については、 *AWS Cloud Development Kit (AWS CDK) API リファレンス*のクラス CfnOutput (コンストラクト) で`CfnOutput`利用可能なコンストラクトのドキュメントを参照してください。 [ CfnOutput ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CfnOutput.html) 対応する UI: 設定タブ/**CloudFormation 出力変数** ## CloudAssemblyRootPath (*CDKDeploy*/Configuration/**CloudAssemblyRootPath**) (オプション) AWS CDK アプリのスタックを ( `cdk synth`オペレーションを使用して) クラウドアセンブリに既に合成している場合は、クラウドアセンブリディレクトリのルートパス () を指定します`cdk.out`。指定されたクラウドアセンブリディレクトリにある CloudFormation テンプレートは、 `cdk deploy --app` コマンド AWS アカウントを使用してデプロイアクションによってに**AWS CDK デプロイ**されます。`--app` オプションが存在する場合、`cdk synth` オペレーションは実行されません。クラウドアセンブリディレクトリを指定しない場合、**[AWS CDK デプロイ]** アクションは `--app` オプションなしで `cdk deploy` コマンドを実行します。`--app` オプションがない場合、`cdk deploy`オペレーションは (`cdk synth`) を合成し、 AWS CDK アプリをにデプロイします AWS アカウント。 **AWS CDK 「デプロイ」アクションが実行時に合成できるときに、既存の合成されたクラウドアセンブリを指定するのはなぜですか?** 既存の合成されたクラウドアセンブリを指定して、次のことを行えます。 + **「デプロイ」アクションを実行するたびに、まったく同じリソースセットがAWS CDK デプロイされていることを確認します。** クラウドアセンブリを指定しない場合、**[AWS CDK デプロイ]** アクションは実行時期に応じて異なるファイルを合成してデプロイできます。例えば、**[AWS CDK デプロイ]** アクションは、テストステージ中に 1 つの依存関係のセット、および本番ステージ中に別の依存関係のセット (それらの依存関係がステージ間で変更された場合) を使用してクラウドアセンブリを合成する場合があります。テスト対象とデプロイ対象との正確なパリティを保証するには、一度合成してから、**[Path to cloud assembly directory]** フィールド (ビジュアルエディタ) または `CloudAssemblyRootPath` プロパティ (YAML エディタ) を使用して、既に合成済みのクラウドアセンブリを指定することをお勧めします。 + ** AWS CDK アプリで非標準パッケージマネージャーとツールを使用する** `synth` オペレーション中、**[AWS CDK デプロイ]** アクションは npm や pip などの標準ツールを使用してアプリを実行しようとします。アクションがこれらのツールを使用してアプリを正常に実行できない場合、合成は行われず、アクションは失敗します。この問題を回避するには、アプリの `cdk.json` ファイルで AWS CDK アプリを正常に実行するために必要な正確なコマンドを指定し、**AWS CDK デプロイ**アクションを含まないメソッドを使用してアプリを合成します。クラウドアセンブリが生成されたら、**[AWS CDK デプロイ]** アクションの **[クラウドアセンブリディレクトリへのパス]** フィールド (ビジュアルエディタ) または `CloudAssemblyRootPath` プロパティ (YAML エディタ) で指定できます。 AWS CDK アプリをインストールして実行するためのコマンドを含めるように `cdk.json` ファイルを設定する方法については、[「アプリコマンドの指定](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-app-command)」を参照してください。 `cdk deploy` および `cdk synth` コマンド、ならびに `--app` オプションの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[スタックのデプロイ](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy)」、「[スタックの合成](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-synth)」、「[合成のスキップ](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy-nosynth)」を参照してください。クラウドアセンブリの詳細については、「*AWS Cloud Development Kit (AWS CDK) API リファレンス*」の「[クラウドアセンブリ](https://docs.aws.amazon.com/cdk/api/v2/docs/cloud-assembly-schema-readme.html)」を参照してください。対応する UI: [設定] タブ/**クラウドアセンブリディレクトリへのパス** # ワークフローを使用して AWS CDK アプリをブートストラップするこのセクションでは、CodeCatalyst ワークフローを使用して AWS CDK アプリケーションをブートストラップする方法について説明します。これを行うには、**[AWS CDK ブートストラップ]** アクションをワークフローに追加する必要があります。**[AWS CDK ブートストラップ]** アクションは、[[最新のテンプレート]](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-template) を使用して、 AWS 環境でブートストラップスタックをプロビジョニングします。ブートストラップスタックが既に存在する場合、アクションは必要に応じてそれを更新します。にブートストラップスタックがあること AWS は、 AWS CDK アプリケーションをデプロイするための前提条件です。ジョブのブックマークの詳細については、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[ジョブブックマーク](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)」を参照してください。 **Topics** + [ ## AWS CDK 「ブートストラップ」アクションを使用するタイミング ](#cdk-boot-action-when-to-use) + [ ## AWS CDK 「ブートストラップ」アクションの仕組み ](#cdk-boot-action-how-it-works) + [ ## AWS CDK 「ブートストラップ」アクションで使用される CDK CLI バージョン ](#cdk-boot-action-cdk-version) + [ ## AWS CDK 「ブートストラップ」アクションで使用されるランタイムイメージ ](#cdk-boot-action-runtime) + [ # 例: AWS CDK アプリケーションのブートストラップ ](cdk-boot-action-example-workflow.md) + [ # AWS CDK 「ブートストラップ」アクションの追加 ](cdk-boot-action-add.md) + [ # 「AWS CDK ブートストラップ」変数 ](cdk-boot-action-variables.md) + [ # 「AWS CDK ブートストラップ」アクション YAML ](cdk-boot-action-ref.md) ## AWS CDK 「ブートストラップ」アクションを使用するタイミング AWS CDK アプリケーションをデプロイするワークフローがあり、ブートストラップスタックを同時にデプロイ (および必要に応じて更新) する場合は、このアクションを使用します。この場合、**AWS CDK ブートストラップ**アクションを、 AWS CDK アプリケーションをデプロイするワークフローと同じワークフローに追加します。次のいずれかに当てはまる場合は、このアクションを**使用しないでください**。 + 既に別のメカニズムを使用してブートストラップスタックをデプロイしており、そのままにしたい (更新なし)。 + [カスタムブートストラップテンプレート](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-customizing) を使用します。これはブート**[AWS CDK ストラップ]** アクションではサポートされていません。 ## AWS CDK 「ブートストラップ」アクションの仕組み **[AWS CDK ブートストラップ]** は次のように動作します。 1. 実行時に、アクションのバージョン 1.0.7 以前を指定した場合、アクションは最新の CDK CLI (Tookit とも呼ばれます) AWS CDK を CodeCatalyst [ビルドイメージ](build-images.md)にダウンロードします。バージョン 1.0.8 以降を指定した場合、アクションは [特定のバージョン](cdk-dep-action.md#cdk-dep-action-cdk-version) の CDK CLI にバンドルされるため、ダウンロードは行われません。 1. アクションは CDK CLI を使用して `cdk bootstrap` コマンドを実行します。このコマンドは、「*AWS Cloud Development Kit (AWS CDK) デベロッパーガイド*」の「[ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)」トピックで説明されているブートストラップタスクを実行します。 ## AWS CDK 「ブートストラップ」アクションで使用される CDK CLI バージョン次の表は、**[AWS CDK ブートストラップ]** アクションのさまざまなバージョンでデフォルトで使用されている CDK CLI のバージョンを示しています。 **注記** デフォルトを上書きできる場合があります。詳細については、「[「AWS CDK ブートストラップ」アクション YAML](cdk-boot-action-ref.md)」の「[CdkCliVersion](cdk-boot-action-ref.md#cdk.boot.cdk.cli.version)」を参照してください。 | 「AWS CDK ブートストラップ」アクションバージョン | AWS CDK CLI バージョン | | --- | --- | | 1.0.0～1.0.7 | 最新 | | 1.0.8 以降 | 2.99.1 | ## AWS CDK 「ブートストラップ」アクションで使用されるランタイムイメージ次の表は、CodeCatalyst が **[AWS CDK ブートストラップ]** アクションのさまざまなバージョンを実行するために使用するランタイム環境イメージを示しています。イメージには、プリインストールされたさまざまなツールのセットが含まれています。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。 **注記** 2024 年 3 月のイメージで利用可能な最新のツールを利用するには、**[AWS CDK ブートストラップ]** アクションをバージョン 2.x にアップグレードすることをお勧めします。アクションをアップグレードするには、ワークフロー定義ファイルの `Identifier` プロパティを `aws/cdk-bootstrap@v2` に設定します。詳細については、「[「AWS CDK デプロイ」アクション YAML](cdk-dep-action-ref.md)」を参照してください。 | 「AWS CDK ブートストラップ」アクションバージョン | ランタイム環境イメージ | | --- | --- | | 1.x | 2022 年 11 月のイメージ | | 2.x | 2024 年 3 月のイメージ | # 例: AWS CDK アプリケーションのブートストラップ「**AWS CDK ** ブートストラップアクションを含むワークフローについては、「[ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)」の「[例: AWS CDK アプリケーションのデプロイ](cdk-dep-action-example-workflow.md)」を参照してください。 # AWS CDK 「ブートストラップ」アクションの追加次の手順を使用して、「**AWS CDK ブートストラップ**」アクションをワークフローに追加します。 **[開始する前に]** 「**AWS CDK ブートストラップ**」アクションを使用する前に、 AWS CDK アプリケーションの準備が整っていることを確認してください。ブートストラップアクションは、ブートストラップの前に AWS CDK アプリケーションを合成します。アプリケーションは、 AWS CDKでサポートされている任意のプログラミング言語で記述できます。 AWS CDK アプリファイルが次の場所で使用可能であることを確認します。 + CodeCatalyst [[ソースリポジトリ]](source.md)、または + 別のワークフローアクションによって生成された CodeCatalyst [出力アーティファクト](workflows-working-artifacts.md) ------ #### [ Visual ] **ビジュアルエディタを使用してAWS CDK 「ブートストラップ」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. 「**AWS CDK ブートストラップ**」アクションを検索し、次のいずれかを実行します。 + プラス記号 (**\$1**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + 「**AWS CDK ブートストラップ**」を選択します。[アクションの詳細] ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]**、**[設定]**、**[出力]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「AWS CDK ブートストラップ」アクション YAML](cdk-boot-action-ref.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 **注記** **[AWS CDK ブートストラップ]** アクションが `npm install` エラーで失敗した場合、エラーを修正する方法については、「[「npm install」エラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-npm)」を参照してください。 ------ #### [ YAML ] **YAML エディタを使用してAWS CDK 「ブートストラップ」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[AWS CDK ブートストラップ]** アクションを検索し、**[\$1]** を選択してワークフロー図に追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「AWS CDK ブートストラップ」アクション YAML](cdk-boot-action-ref.md)」に記載されています。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 **注記** **[AWS CDK ブートストラップ]** アクションが `npm install` エラーで失敗した場合、エラーを修正する方法については、「[「npm install」エラーを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-npm)」を参照してください。 ------ # 「AWS CDK ブートストラップ」変数 **[AWS CDK ブートストラップ]** アクションは、実行時に次の変数を生成して設定します。これらは*事前定義済み変数*と呼ばれます。ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください | キー | 値 | | --- | --- | | deployment-platform | デプロイプラットフォームの名前。 `AWS:CloudFormation` にハードコードされています。 | | リージョン | ワークフローの実行中に AWS CDK ブートストラップスタック AWS リージョンがデプロイされたのリージョンコード。例: `us-west-2` | | stack-id | デプロイされた AWS CDK ブートストラップスタックの Amazon リソースネーム (ARN)。例: `arn:aws:cloudformation:us-west-2:111122223333:stack/codecatalyst-cdk-bootstrap-stack/6aad4380-100a-11ec-a10a-03b8a84d40df` | | SKIP-DEPLOYMENT | の値は、ワークフローの実行中に AWS CDK ブートストラップスタックのデプロイがスキップされた`true`ことを示します。前回のデプロイ以降にスタックに変更がない場合、スタックのデプロイはスキップされます。この変数は、値が `true` の場合にのみ生成されます。 `true` にハードコードされています。 | # 「AWS CDK ブートストラップ」アクション YAML 以下は、**[AWS CDK ブートストラップ]** アクションの YAML 定義です。このアクションの使用方法については、「[ワークフローを使用して AWS CDK アプリをブートストラップする](cdk-boot-action.md)」を参照してください。このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. CDKBootstrapAction\$1nn: Identifier: aws/cdk-bootstrap@v2 DependsOn: - action-name Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - artifact-name Outputs: Artifacts: - Name: cdk_bootstrap_artifacts Files: - "cdk.out/**/*" Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Configuration: Region: us-west-2 CdkCliVersion: version ``` ## CDKBootstrapAction (必須) アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。デフォルト: `CDKBootstrapAction_nn`。対応する UI: [設定] タブ/**[アクション表示名]** ## Identifier (*CDKBootstrapAction*/**Identifier**) (必須) アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。 **注記** `aws/cdk-bootstrap@v2` を指定すると、Node.js 18 などの新しいツールを含む [2024 年](build-images.md#build.default-image) 3 月の画像でアクションが実行されます。`aws/cdk-bootstrap@v1` を指定すると、Node.js 16 などの古いツールを含む [2022 年 11 月のイメージ](build-images.md#build.previous-image)でアクションが実行されます。デフォルト: `aws/cdk-bootstrap@v2`。対応する UI: ワークフロー図/CDKBootstrapAction\$1nn/**aws/cdk-bootstrap@v2** ラベル ## DependsOn (*CDKBootstrapAction*/**DependsOn**) (オプション) このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。対応する UI: [入力] タブ/**[依存 - オプション]** ## Compute (*CDKBootstrapAction*/**Compute**) (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。対応する UI: *[なし]* ## Type (*CDKBootstrapAction*/Compute/**Type**) ([Compute](#cdk.boot.computename) が含まれている場合は必須) コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。 + **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ) アクション実行時の柔軟性を目的として最適化されています。 + **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ) アクションの起動速度を最適化しました。コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングタイプ]** ## Fleet (*CDKBootstrapAction*/Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。対応する UI: [設定] タブ/[高度な設定 - オプション]/**[コンピューティングフリート]** ## Timeout (*CDKBootstrapAction*/**Timeout**) (必須) CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。対応する UI: [設定] タブ/**[タイムアウト - オプション]** ## Inputs (*CDKBootstrapAction*/**Inputs**) (オプション) `Inputs` セクションでは、ワークフローの実行中に **[AWS CDK ブートストラップ]** アクションに必要なデータを定義します。対応する UI: **[入力]** タブ **注記** **[AWS CDK ブートストラップ]** アクションごとに 1 つの入力 (ソースまたはアーティファクト) のみが許可されます。 ## Sources (*CDKBootstrapAction*/Inputs/**Sources**) ( AWS CDK アプリがソースリポジトリに保存されている場合は必須) AWS CDK アプリがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。**[AWS CDK ブートストラップ]** アクションは、ブートストラッププロセスを開始する前に、このリポジトリ内のアプリケーションを合成します。現在、サポートされているリポジトリラベルは `WorkflowSource` のみです。 AWS CDK アプリがソースリポジトリに含まれていない場合は、別のアクションによって生成されたアーティファクトに存在する必要があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。対応する UI: 入力タブ/**ソース - オプション** ## Artifacts - input (*CDKBootstrapAction*/Inputs/**Artifacts**) ( AWS CDK アプリが前のアクションの[出力アーティファクト](workflows-working-artifacts-output.md)に保存されている場合に必要です) AWS CDK アプリが前のアクションによって生成されたアーティファクトに含まれている場合は、ここでそのアーティファクトを指定します。**[AWS CDK ブートストラップ]** アクションは、ブートストラッププロセスを開始する前に、指定されたアーティファクト内のアプリケーションを CloudFormation テンプレートに合成します。 AWS CDK アプリがアーティファクトに含まれていない場合は、ソースリポジトリに存在する必要があります。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: 入力タブ/**アーティファクト - オプション** ## Outputs (*CDKBootstrapAction*/**Outputs**) (オプション) ワークフローの実行中にアクションによって出力されるデータを定義します。対応する UI: **[出力]** タブ ## Artifacts - output (*CDKBootstrapAction*/Outputs/**Artifacts**) (オプション) アクションによって生成されたアーティファクトを指定します。このアーティファクトは、他のアクションの入力として参照できます。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [出力] タブ/**[アーティファクト]** ## Name (*CDKBootstrapAction*/Outputs/Artifacts/**Name**) ([Artifacts - output](#cdk.boot.outputs.artifacts) が含まれている場合は必須) 実行時に**AWS CDK ブートストラップ**アクションによって合成される CloudFormation テンプレートを含むアーティファクトの名前を指定します。デフォルト値は `cdk_bootstrap_artifacts` です。アーティファクトを指定しない場合、アクションはテンプレートを合成しますが、アーティファクトには保存されません。テストまたはトラブルシューティングの目的で、合成されたテンプレートをアーティファクトに保存して、その記録を保持することを検討してください。対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドアーティファクト名]** ## Files (*CDKBootstrapAction*/Outputs/Artifacts/**Files**) ([Artifacts - output](#cdk.boot.outputs.artifacts) が含まれている場合は必須) アーティファクトに含めるファイルを指定します。 AWS CDK アプリの合成 CloudFormation されたテンプレートを含める`"cdk.out/**/*"`には、を指定する必要があります。 **注記** `cdk.out` は、合成されたファイルが保存されるデフォルトのディレクトリです。`cdk.json` ファイルで `cdk.out` 以外の出力ディレクトリを指定した場合は、`cdk.out` の代わりに、ここでそのディレクトリを指定します。対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドで生成されるファイル]** ## Environment (*CDKBootstrapAction*/**Environment**) (必須) アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウントおよびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用してに接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。 **注記** デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。環境タグ付けの詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: [設定] タブ/**[環境]** ## Name (*CDKBootstrapAction*/Environment/**Name**) ([Environment](#cdk.boot.environment) が含まれている場合は必須) アクションに関連付ける既存の環境の名前を指定します。対応する UI: [設定] タブ/**[環境]** ## Connections (*CDKBootstrapAction*/Environment/**Connections**) (新しいバージョンのアクションでは任意。古いバージョンでは必須) アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。アカウント接続を指定しない場合: + アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 + デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Name (*CDKBootstrapAction*/Environment/Connections/**Name**) ([Connections](#cdk.boot.environment.connections) が含まれている場合は必須) アカウント接続の名前を指定します。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Role (*CDKBootstrapAction*/Environment/Connections/**Role**) ([Connections](#cdk.boot.environment.connections) が含まれている場合は必須) **AWS CDK ブートストラップ**アクションがブートストラップスタックにアクセスして AWS 追加するために使用する IAM ロールの名前を指定します。[ロールを CodeCatalyst スペースに追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。 IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、適切なポリシーがあることを確認してください。必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]** ## Configuration (*CDKBootstrapAction*/**Configuration**) (必須) アクションの設定プロパティを定義できるセクション。対応する UI: **[設定]** タブ ## Region (*CDKBootstrapAction*/Configuration/**Region**) (必須) ブートストラップスタックをデプロイする AWS リージョンを指定します。このリージョンは、 AWS CDK アプリがデプロイされているリージョンと一致する必要があります。リージョンコードの一覧については、「[リージョンエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#region-names-codes)」を参照してください。対応する UI: [設定] タブ/**[リージョン]** ## CdkCliVersion (*CDKBootstrapAction*/Configuration/**CdkCliVersion**) (オプション) このプロパティは、**[AWS CDK デプロイ]** アクションのバージョン 1.0.13 以降、および **[AWS CDK ブートストラップ]** アクションのバージョン 1.0.8 以降で使用できます。次のいずれかを指定します。 + このアクションで使用する AWS Cloud Development Kit (AWS CDK) コマンドラインインターフェイス (CLI) のフルバージョン (ツールキットとも呼ばれ AWS CDK ます）。例えば、`2.102.1` などです。アプリケーションのビルドとデプロイ時に一貫性と安定性を確保するため、フルバージョンを指定することを検討してください。または + `latest`。CDK CLI の最新の機能と修正を活用するには、`latest` を指定することを検討してください。アクションは、指定されたバージョンの CLI (または最新バージョン) AWS CDK を CodeCatalyst [ビルドイメージ](build-images.md)にダウンロードし、このバージョンを使用して CDK アプリケーションのデプロイまたは環境のブートストラップ AWS に必要なコマンドを実行します。使用できるサポートされている CDK CLI バージョンの一覧については、[[AWS CDK バージョン]](https://docs.aws.amazon.com/cdk/api/versions.html) を参照してください。このプロパティを省略すると、アクションは次のいずれかのトピックで説明されているデフォルトの AWS CDK CLI バージョンを使用します。 + [AWS CDK 「デプロイ」アクションで使用される CDK CLI バージョン](cdk-dep-action.md#cdk-dep-action-cdk-version) + [AWS CDK 「ブートストラップ」アクションで使用される CDK CLI バージョン](cdk-boot-action.md#cdk-boot-action-cdk-version) 対応する UI: 設定タブ/**AWS CDK CLI バージョン** # ワークフローを使用して Amazon S3 にファイルを発行するこのセクションでは、CodeCatalyst ワークフローを使用してファイルを Amazon S3 に発行する方法について説明します。これを行うには、**Amazon S3 発行**アクションをワークフローに追加する必要があります。**Amazon S3 発行**アクションは、ソースディレクトリから Amazon S3 バケットにファイルをコピーします。ソースディレクトリとしては、次の場所を利用できます。 + [ソースリポジトリ](source.md)、または + 別のワークフローアクションによって生成された[出力アーティファクト](workflows-working-artifacts.md) **Topics** + [ ## 「Amazon S3 発行」アクションを使用すべき場合 ](#s3-pub-action-when-to-use) + [ ## 「Amazon S3 発行」アクションで使用されるランタイムイメージ ](#s3-pub-action-runtime) + [ # 例: Amazon S3 にファイルを発行する ](s3-pub-action-example-workflow.md) + [ # 「Amazon S3 発行」アクションの追加 ](s3-pub-action-add.md) + [ # 「Amazon S3 発行」アクションの YAML ](s3-pub-action-ref.md) ## 「Amazon S3 発行」アクションを使用すべき場合次の場合は、このアクションを使用します。 + ワークフローで生成されたファイルを Amazon S3 に保存する必要があります。例えば、ワークフローで静的ウェブサイトをビルドして、それを Amazon S3 でホストする場合です。この場合、ワークフローには、[ビルド](build-add-action.md)アクション (サイトの HTML とサポートファイルをビルドする) と **Amazon S3 発行**アクション (ファイルを Amazon S3 にコピーする) が含まれます。 + ソースリポジトリに含まれるファイルを Amazon S3 に保存する必要があります。例えば、ソースリポジトリに含まれるアプリケーションソースファイルを毎晩 Amazon S3 にアーカイブする場合です。 ## 「Amazon S3 発行」アクションで使用されるランタイムイメージ **Amazon S3 発行**アクションは、[2022 年 11 月のイメージ](build-images.md#build.previous-image)で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。 # 例: Amazon S3 にファイルを発行する次のワークフローの例には、**Amazon S3 発行**アクションとビルドアクションが含まれています。このワークフローは、静的ドキュメントウェブサイトをビルドして、サイトがホストされる Amazon S3 に発行します。このワークフローは、連続して実行される次の構成要素で構成されます。 + **トリガー** – ソースリポジトリに変更をプッシュすると、このトリガーによってワークフローが自動的に開始されます。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + **ビルド**アクション (`BuildDocs`) – トリガーされると、アクションは静的ドキュメントウェブサイト (`mkdocs build`) をビルドし、関連する HTML ファイルとサポートメタデータを `MyDocsSite` というアーティファクトに追加します。ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。 + **Amazon S3 発行**アクション (`PublishToS3`) – ビルドアクションが完了すると、このアクションはアーティファクト `MyDocsSite` のサイトを、ホスティングのために Amazon S3 にコピーします。 **注記** 次のワークフロー例は説明を目的としており、追加の設定なしでは機能しません。 **注記** 次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。このセクションを省略する場合は、環境の**デフォルトの IAM ロール**フィールドで指定されたロールに、**Amazon S3 発行**アクションに必要なアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。**Amazon S3 発行**アクションに必要なアクセス許可と信頼ポリシーの詳細については、[「Amazon S3 発行」アクションの YAML](s3-pub-action-ref.md) の [Role](s3-pub-action-ref.md#s3.pub.environment.connections.role) プロパティの説明を参照してください。 ``` Name: codecatalyst-s3-publish-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: BuildDocs: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: echo BuildDocs started on `date` - Run: pip install --upgrade pip - Run: pip install mkdocs - Run: mkdocs build - Run: echo BuildDocs completed on `date` Outputs: Artifacts: - Name: MyDocsSite Files: - "site/**/*" PublishToS3: Identifier: aws/s3-publish@v1 Environment: Name: codecatalyst-s3-publish-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-s3-publish-build-role Inputs: Sources: - WorkflowSource Artifacts: - MyDocsSite Configuration: DestinationBucketName: amzn-s3-demo-bucket SourcePath: /artifacts/PublishToS3/MyDocSite/site TargetPath: my/docs/site ``` # 「Amazon S3 発行」アクションの追加次の手順を使用して、**Amazon S3 発行**アクションをワークフローに追加します。 ------ #### [ Visual ] **ビジュアルエディタを使用して「Amazon S3 発行」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[Amazon S3 発行]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[Amazon S3 発行]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]**、**[設定]**、**[出力]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「Amazon S3 発行」アクションの YAML](s3-pub-action-ref.md)」を参照してください。このリファレンスでは、YAML エディタとビジュアルエディタの両方に表示される各フィールド (および対応する YAML プロパティ値) に関する詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して「Amazon S3 発行」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[Amazon S3 発行]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[Amazon S3 発行]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「Amazon S3 発行」アクションの YAML](s3-pub-action-ref.md)」に記載されています。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 「Amazon S3 発行」アクションの YAML 以下は、**Amazon S3 発行**アクションの YAML 定義です。このアクションの使用方法については、「[ワークフローを使用して Amazon S3 にファイルを発行する](s3-pub-action.md)」を参照してください。このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. S3Publish\$1nn: Identifier: aws/s3-publish@v1 DependsOn: - build-action Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Inputs: Sources: - source-name-1 Artifacts: - artifact-name Variables: - Name: variable-name-1 Value: variable-value-1 - Name: variable-name-2 Value: variable-value-2 Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Configuration: SourcePath: my/source DestinationBucketName: amzn-s3-demo-bucket TargetPath: my/target ``` ## S3Publish (必須) アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。デフォルト: `S3Publish_nn`。対応する UI: [設定] タブ/**[アクション名]** ## Identifier (*S3Publish*/**Identifier**) (必須) アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。デフォルト: `aws/s3-publish@v1`。対応する UI: ワークフロー図/S3Publish\$1nn/**aws/s3-publish@v1** ラベル ## DependsOn (*S3Publish*/**DependsOn**) (オプション) このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。対応する UI: [入力] タブ/**[依存 - オプション]** ## Compute (*S3Publish*/**Compute**) (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。対応する UI: *[なし]* ## Type (*S3Publish*/Compute/**Type**) ([Compute](#s3.pub.computename) が含まれている場合は必須) コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。 + **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ) アクション実行時の柔軟性を目的として最適化されています。 + **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ) アクションの起動速度を最適化しました。コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。対応する UI: [設定] タブ/**[コンピューティングタイプ]** ## Fleet (*S3Publish*/Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。対応する UI: [設定] タブ/**[コンピューティングフリート]** ## Timeout (*S3Publish*/**Timeout**) (必須) CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。対応する UI: [設定] タブ/**[タイムアウト - オプション]** ## Inputs (*S3Publish*/**Inputs**) (オプション) `Inputs` セクションでは、ワークフローの実行中に `S3Publish` に必要なデータを定義します。 **注記** **AWS CDK デプロイ**アクションごとに最大 4 つの入力 (1 つのソースと 3 つのアーティファクト) が許可されます。変数はこの合計にはカウントされません。異なる入力 (ソースとアーティファクトなど) にあるファイルを参照する必要がある場合、ソース入力はプライマリ入力で、アーティファクトはセカンダリ入力になります。セカンダリ入力内のファイルへの参照には、プライマリからファイルを区別するための特別なプレフィックスが付きます。詳細については、「[例: 複数のアーティファクトでのファイルの参照](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)」を参照してください。対応する UI: **入力**タブ ## Sources (*S3Publish*/Inputs/**Sources**) (Amazon S3 に発行するファイルがソースリポジトリに保存されている場合は必須） Amazon S3 に発行するファイルがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。現在サポートされているラベルは、`WorkflowSource` のみです。 Amazon S3 に発行するファイルがソースリポジトリに含まれていない場合は、別のアクションによって生成されたアーティファクトに存在する必要があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。対応する UI: 入力タブ/**ソース - オプション** ## Artifacts - input (*S3Publish*/Inputs/**Artifacts**) (Amazon S3 に発行するファイルが前のアクションの[出力アーティファクト](workflows-working-artifacts-output.md)に保存されている場合は必須） Amazon S3 に発行するファイルが、前のアクションによって生成されたアーティファクトに含まれている場合は、ここでそのアーティファクトを指定します。ファイルがアーティファクトに含まれていない場合は、ソースリポジトリに存在する必要があります。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [設定] タブ/**[アーティファクト - オプション]** ## Variables - input (*S3Publish*/Inputs/**Variables**) (オプション) アクションで使用できるようにしたい入力変数を定義する名前と値のペアのシーケンスを指定します。変数名に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、変数名で特殊文字とスペースを有効にすることはできません。変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。対応する UI: [入力] タブ/**[変数 - オプション]** ## Environment (*S3Publish*/**Environment**) (必須) アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウントおよびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用してに接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。 **注記** デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。環境タグ付けの詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: [設定] タブ/**[環境]** ## Name (*S3Publish*/Environment/**Name**) ([Environment](#s3.pub.environment) が含まれている場合は必須) アクションに関連付ける既存の環境の名前を指定します。対応する UI: [設定] タブ/**[環境]** ## Connections (*S3Publish*/Environment/**Connections**) (新しいバージョンのアクションでは任意。古いバージョンでは必須) アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。アカウント接続を指定しない場合: + アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 + デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Name (*S3Publish*/Environment/Connections/**Name**) ([Connections](#s3.pub.environment.connections) が含まれている場合は必須) アカウント接続の名前を指定します。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Role (*S3Publish*/Environment/Connections/**Role**) ([Connections](#s3.pub.environment.connections) が含まれている場合は必須) **Amazon S3 発行**アクションがアクセスおよび Amazon S3 へのファイル AWS のコピーに使用する IAM ロールの名前を指定します。 Amazon S3 [ロールを CodeCatalyst スペースに追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。 IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーがあることを確認してください。 + 以下のアクセス許可ポリシー: **警告** アクセス許可は、次のポリシーに示すアクセス許可に制限します。範囲の広いアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:ListBucket", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] } ] } ``` ------ + 次のカスタム信頼ポリシー: **注記** 必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]** ## Configuration (*S3Publish*/**Configuration**) (必須) アクションの設定プロパティを定義できるセクション。対応する UI: **[設定]** タブ ## SourcePath (*S3Publish*/Configuration/**SourcePath**) (必須) Amazon S3 に発行するディレクトリまたはファイルの名前とパスを指定します。ディレクトリまたはファイルは、ソースリポジトリまたは前のアクションからのアーティファクトに存在します。ソースリポジトリまたはアーティファクトのルートへの相対パスを指定します。例: `./myFolder/` を指定すると、`/myFolder` の中身が Amazon S3 にコピーされ、内部のディレクトリ構造は保持されます。 `./myFolder/myfile.txt` を指定すると、`myfile.txt` *のみ*が Amazon S3 にコピーされます。（ディレクトリ構造は削除されます。）ワイルドカードは使用できません。 **注記** ディレクトリまたはファイルパスにプレフィックスを追加して、見つけるアーティファクトまたはソースを示す必要がある場合があります。詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」および「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。対応する UI: [設定] タブ/**[ソースパス]** ## DestinationBucketName (*S3Publish*/Configuration/**DestinationBucketName**) (必須) ファイルを発行する Amazon S3 バケットの名前を指定します。対応する UI: [設定] タブ/**[送信先バケット - オプション]** ## TargetPath (*S3Publish*/Configuration/**TargetPath**) (オプション) ファイルを発行する Amazon S3 のディレクトリの名前とパスを指定します。ディレクトリが存在しない場合は作成されます。ディレクトリパスにバケット名を含めることはできません。例: `myS3Folder` `./myS3Folder/myS3Subfolder` 対応する UI: [設定] タブ/**[送信先ディレクトリ - オプション]** # AWS アカウントと VPCs へのデプロイ [CodeCatalyst ワークフロー](workflow.md)を使用すると、アプリケーションやその他のリソースをデプロイして、 AWS クラウド内のと Amazon VPC AWS アカウントをターゲットにできます。 VPCs これらのデプロイを有効にするには、CodeCatalyst 環境を設定する必要があります。 CodeCatalyst *環境*は、[開発環境](https://docs.aws.amazon.com/codecatalyst/latest/userguide/devenvironment.html)と混同されないように、CodeCatalyst [ワークフロー](workflow.md)が接続するターゲット AWS アカウントとオプションの Amazon VPC を定義します。環境は、ターゲットアカウント内の AWS サービスとリソースにアクセスするためにワークフローが必要とする [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)も定義します。複数の環境をセットアップし、開発、テスト、ステージング、本番稼働などの名前を付けることができます。これらの環境にデプロイすると、デプロイに関する情報が環境の CodeCatalyst **[デプロイアクティビティ]** と **[デプロイターゲット]** タブに表示されます。 ## 環境の使用を開始するにはどうすればよいですか？ CodeCatalyst 環境を追加および使用する大まかなステップは次のとおりです。 1. CodeCatalyst スペースで、**1 つ以上の AWS アカウントを接続します**。このプロセス中に、ワークフローが AWS アカウントのリソースにアクセスするために必要な IAM ロールを追加します。詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。 1. CodeCatalyst プロジェクトで、**ステップ 1 のと IAM ロールのいずれかを含む環境を作成します**。 AWS アカウント詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 1. CodeCatalyst プロジェクトで、ワークフローに、ステップ 2 で作成した**環境を指す [[アクション]](workflows-actions.md) を追加します**。詳細については、「[ワークフローへのアクションの追加](workflows-add-action.md)」を参照してください。これで環境が設定されました。アクションは、環境で指定された AWS アカウントにリソースをデプロイできるようになりました。 **注記** Amazon VPC を環境に追加することもできます。詳細については、「*CodeCatalyst 管理ガイド*」と「[VPC と環境の関連付け](deploy-environments-associate-vpc.md)」の「[スペースの VPC 接続の追加](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)」を参照してください。 ## 1 つのワークフロー内に複数の環境が存在する可能性がありますか？はい。ワークフローに複数のアクションが含まれている場合、それらの各アクションに環境を割り当てることができます。例えば、2 つのデプロイアクションを含むワークフローがあるとします。1 つは `my-staging-enviroment` 環境を、もう 1 つは `my-production-environment` 環境を割り当てます。 ## 環境をサポートするワークフローアクションはどれですか？リソースを AWS クラウドにデプロイするワークフローアクション、または他の理由 (モニタリングやレポートなど) で AWS サービスと通信するワークフローアクションは、環境をサポートします。 ## CodeCatalyst にデプロイ情報を表示することをサポートするアクションはどれですか？環境をサポートするワークフローアクションのうち、CodeCatalyst コンソールの **[デプロイアクティビティ]** と **[デプロイターゲット]** ページにデプロイ情報が表示されるのはごく少数です。次のワークフローアクションは、デプロイ情報の表示をサポートします。 + ** CloudFormation スタックをデプロイする** – 詳細については、「」を参照してください。 [CloudFormation スタックのデプロイ](deploy-action-cfn.md) + **Amazon ECS をデプロイ** – 詳細については、「[ワークフローを使用した Amazon ECS へのデプロイ](deploy-action-ecs.md)」を参照してください。 + **Kubernetes クラスターにデプロイ**する – 詳細については、「[ワークフローを使用して Amazon EKS にデプロイする](deploy-action-eks.md)」を参照してください。 + **AWS CDK デプロイ** – 詳細については、「」を参照してください。 [ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md) ## サポート対象のリージョン **[環境]** ページには、任意の AWS リージョンのリソースを表示できます。 ## 環境は必須ですか？環境は、割り当てられたワークフローアクションがリソースを AWS クラウドにデプロイする場合や、その他の理由 (モニタリングやレポートなど) で AWS サービスと通信する場合に必須です。たとえば、アプリケーションを構築するビルドアクションがあっても、 AWS アカウントまたは Amazon VPC と通信する必要がない場合は、アクションに環境を割り当てる必要はありません。ただし、ビルドアクションが AWS アカウントの Amazon CloudWatch サービスにログを送信する場合は、アクションに環境を割り当てる必要があります。 **Topics** + [ ## 環境の使用を開始するにはどうすればよいですか？ ](#deploy-environments-get-started) + [ ## 1 つのワークフロー内に複数の環境が存在する可能性がありますか？ ](#deploy-environments-multiple) + [ ## 環境をサポートするワークフローアクションはどれですか？ ](#deploy-environments-supported) + [ ## CodeCatalyst にデプロイ情報を表示することをサポートするアクションはどれですか？ ](#deploy-environments-supported-targets) + [ ## サポート対象のリージョン ](#deploy-environments-supported-regions) + [ ## 環境は必須ですか？ ](#deploy-environments-optional-or-mandatory) + [ # 環境を作成する ](deploy-environments-creating-environment.md) + [ # 環境とアクションの関連付け ](deploy-environments-add-app-to-environment.md) + [ # VPC と環境の関連付け ](deploy-environments-associate-vpc.md) + [ # 環境 AWS アカウントへのの関連付け ](deploy-environments-associate-account.md) + [ # アクションの IAM ロールの変更 ](deploy-environments-switch-role.md) # 環境を作成する以下の手順に従って、後でワークフローアクションに関連付けることができる環境を作成します。 **[開始する前に]** また、以下も必要になります。 + CodeCatalyst スペース。詳細については、「[CodeCatalyst をセットアップしてサインインするCodeCatalyst をセットアップしてサインインする](setting-up-topnode.md)」を参照してください。 + CodeCatalyst プロジェクト。詳細については、「[ブループリントを使用したプロジェクトの作成](projects-create.md#projects-create-console-template)」を参照してください。 + ワークフローアクションがアクセスする必要がある IAM ロールを含む AWS アカウント接続 AWS。アカウント接続と作成の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。環境ごとに最大 1 つのアカウント接続を使用できます。 **注記** アカウント接続なしで環境を作成できますが、後で接続に戻って追加する必要があります。 + 次のいずれかの CodeCatalyst ロール: + **スペース管理者** + **プロジェクト管理者** + **寄稿者** **注記** **[Contributor ロール]** がある場合は、環境を作成できますが、 AWS アカウント接続に関連付けることはできません。環境を AWS アカウント接続に関連付けるには、**スペース管理者**または**プロジェクト管理者**ロールを持つユーザーに依頼する必要があります。ロールとアクセス許可の詳細については、「[ユーザーにプロジェクトアクセス許可を付与する](projects-members.md)」を参照してください。 **環境を作成する方法** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。 1. **[環境名]** に、**Production** や **Staging** などの名前を入力します。 1. **[環境タイプ]** で、次のいずれかを選択します。 + **非本番環境** – アプリケーションをテストして、本番環境に移行する前に意図したとおりに動作していることを確認することができる環境。 + **本番稼働用** - 公開され、完成したアプリケーションをホストする「ライブ」環境。 **[本番稼働用]** を選択すると、環境が関連付けられているアクションの横にある UI に **[本番稼働用]** バッジが表示されます。このバッジは、本番稼働環境にデプロイされているアクションをすばやく確認できます。バッジの外観を除き、本番稼働環境と非本番稼働環境の間に違いはありません。 1. (オプション) **[説明]**で、「**Production environment for the hello-world app**」のような説明を入力します。 1. **AWS アカウント接続 - オプション**で、この環境に関連付ける AWS アカウント接続を選択します。環境に割り当てられたワークフローアクションが AWS アカウントに接続できるようになります。CodeCatalyst で AWS アカウント接続を作成する方法の詳細については、「」を参照してください[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)。使用する AWS アカウント接続がリストされていない場合は、プロジェクトで許可されていない可能性があります。詳細については、「*Amazon CodeCatalyst 管理者ガイド*」の「[プロジェクト制限アカウント接続の設定](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)」を参照してください。 1. **[デフォルトの IAM ロール]** で、この環境に関連付ける IAM ロールを選択します。この環境に割り当てられたワークフローアクションはこの IAM ロールを継承し、これを使用してのサービスとリソースに接続できます AWS アカウント。環境を複数のアクションに割り当てる必要があり、これらのアクションにここで指定したデフォルトとは異なる IAM ロールが必要な場合は、**[ロールの切り替え]** オプションを使用して、各アクションの **[設定]** タブで異なるロールを指定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。デフォルトとして使用する IAM ロールが表示されていない場合は、まだ AWS アカウント接続に追加していない可能性があります。アカウント接続に IAM ロールを追加するには、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。 1. (オプション) **[VPC 接続]** で、この環境に関連付ける VPC 接続を選択します。VPC 接続の作成の詳細については、「*Amazon CodeCatalyst 管理者ガイド*」の「[Amazon Virtual Private Clouds の管理](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.html)」を参照してください。使用する VPC 接続が表示されていない場合は、プロジェクトで許可されていない AWS アカウント接続が含まれている可能性があります。詳細については、「*Amazon CodeCatalyst 管理者ガイド*」の「[プロジェクト制限アカウント接続の設定](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)」を参照してください。 1. [**環境を作成**] を選択します。CodeCatalyst は空の環境を作成します。 **次の手順** + 環境を作成したら、ワークフローアクションに関連付ける準備が整いました。詳細については、「[環境とアクションの関連付け](deploy-environments-add-app-to-environment.md)」を参照してください。 # 環境とアクションの関連付け [サポートされているワークフローアクション](deploy-environments.md#deploy-environments-supported)に環境を関連付けると、環境の AWS アカウント、デフォルトの IAM ロール、およびオプションの Amazon VPC がアクションに割り当てられます。その後、アクションは IAM ロールを使用して AWS アカウントに接続してデプロイし、オプションの Amazon VPC にも接続できます。環境をアクションに関連付けるには、次の手順に従います。 ## ステップ 1: 環境をワークフローアクションに関連付ける環境をワークフローアクションに関連付けるには、次の手順に従います。 ------ #### [ Visual ] **ビジュアルエディタを使用して環境をワークフローアクションに関連付けるには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、環境でサポートされているアクションを選択します。詳細については、「[CodeCatalyst にデプロイ情報を表示することをサポートするアクションはどれですか？](deploy-environments.md#deploy-environments-supported-targets)」を参照してください。 1. **[設定]** タブを選択し、次のように **[環境]** フィールドに情報を指定します。 **環境** アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウントおよびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用してに接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。 **注記** デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。環境タグ付けの詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 1. (オプション) アクションに関連付けられた IAM ロールを変更します。アクションのアクセス許可のセットが間違っている場合は、ロールを変更できます。ロールを作成するには: 1. 「***my-environment* とは？**」ボックスで、縦楕円アイコン (![\[Ellipsis.\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/elipsis.png)) を選択します。 1. 次のいずれかを選択します。 + **[ロールの切り替え]** このオプションを選択すると、このアクションで使用される IAM ロールが変更され、このアクションのみが変更されます。その他のアクションでは、引き続き、関連付けられた環境で指定されたデフォルトの IAM ロールを使用します。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。 + **[環境を編集]** 環境に表示されるデフォルトの IAM ロールを変更するには、このオプションを選択します。このオプションを選択すると、アクション、および同じ環境に関連付けられている他のアクションは、新しいデフォルトの IAM ロールを使用して開始します。 **重要** デフォルトの IAM ロールを更新するときは注意してください。ロールを変更すると、環境を共有するすべてのアクションに対してロールのアクセス許可が十分でない場合、アクションが失敗する可能性があります。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して環境をワークフローアクションに関連付けるには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 環境に関連付けるワークフローアクションで、次のようなコードを追加します。 ``` action-name: Environment: Name: environment-name ``` 詳細については、トピック「[アクションタイプ](workflows-actions.md#workflows-actions-types)」を参照してください。このトピックには、YAML リファレンスを含む各アクションのドキュメントへのリンクが含まれています。 1. (オプション) 環境に一覧表示されているデフォルトの IAM ロールとは異なるロールをアクションで使用する場合は、使用するロールを含む `Connections:` セクションを追加します。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ ## ステップ 2: デプロイアクティビティページを入力する環境をワークフローアクションに関連付けると、CodeCatalyst コンソールの **[環境]** セクションの **[デプロイアクティビティ]** と **[デプロイターゲット]** ページにデプロイ情報を入力できます。以下の手順に従って、これらのページを入力します。 **注記** CodeCatalyst コンソールにデプロイ情報が表示されるのは、いくつかのアクションのみです。詳細については、「[CodeCatalyst にデプロイ情報を表示することをサポートするアクションはどれですか？](deploy-environments.md#deploy-environments-supported-targets)」を参照してください。 **CodeCatalyst にデプロイ情報を追加するには** 1. [ステップ 1: 環境をワークフローアクションに関連付ける](#deploy-environments-add-app-to-environment-assoc) で変更をコミットしたときにワークフローの実行が自動的に開始しない場合は、次のように手動で実行を開始します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[Run]** (実行) を選択します。ワークフローの実行により新しいデプロイが開始し、CodeCatalyst がデプロイ情報を CodeCatalyst に追加します。 1. デプロイアクティビティが CodeCatalyst コンソールに追加されていることを確認します。 1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。 1. 環境を選択します (例: `Production`)。 1. **[デプロイアクティビティ]** タブを選択し、デプロイの **[ステータス]** が **[成功しました]** であることを確認します。これは、ワークフローの実行がアプリケーションリソースを正常にデプロイしたことを示します。 1. **[デプロイターゲット]** タブを選択し、アプリケーションリソースが表示されることを確認します。 # VPC と環境の関連付けアクションが VPC 接続を持つ環境で構成されている場合、アクションは VPC に接続して実行され、関連する VPC によって指定されたネットワークルールとアクセスリソースに従います。同じ VPC 接続を 1 つ以上の環境で使用できます。 VPC 接続を環境に関連付けるには、次の手順を使用します。 **VPC 接続を環境に関連付けるには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。 1. 環境を選択します (例: `Production`)。 1. **[環境プロパティ]** タブを選択します。 1. **[VPC 接続を管理]** を選択し、目的の VPC 接続を選択し、**[確認]** を選択します。これにより、選択した VPC 接続がこの環境に関連付けられます。 **注記** 使用する VPC 接続が表示されていない場合は、プロジェクトで許可されていない AWS アカウント接続が含まれている可能性があります。詳細については、「*Amazon CodeCatalyst 管理者ガイド*」の「[プロジェクト制限アカウント接続の設定](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)」を参照してください。詳細については、「*CodeCatalyst 管理者ガイド*」の「[Amazon Virtual Private Clouds の管理](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.html)」を参照してください。 # 環境 AWS アカウントへのの関連付け環境 AWS アカウントとを関連付けるには、次の手順を使用します。を環境に関連付ける AWS アカウントと、環境に割り当てられたワークフローアクションがに接続できるようになります AWS アカウント。アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。 **[開始する前に]** また、以下も必要になります。 + ワークフローアクションがアクセスする必要がある IAM ロールを含む AWS アカウント接続 AWS。アカウント接続と作成の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。環境ごとに最大 1 つのアカウント接続を使用できます。 + 次のいずれかの CodeCatalyst ロール: **[スペース管理者]** または **[プロジェクト管理者]**。詳細については、「[ユーザーにプロジェクトアクセス許可を付与する](projects-members.md)」を参照してください。 **AWS アカウントを環境に関連付けるには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。 1. 環境を選択します (例: `Production`)。 1. **[環境を編集]** を選択します。 1. **[環境プロパティ]** で、**[AWS アカウント接続 - オプション]** ドロップダウンリストで、目的の AWS アカウントを選択します。使用する AWS アカウント接続がリストされていない場合は、プロジェクトで許可されていない可能性があります。詳細については、「*Amazon CodeCatalyst 管理者ガイド*」の「[プロジェクト制限アカウント接続の設定](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-accounts-restriction.html)」を参照してください。 1. **[デフォルトの IAM ロール]** で、この環境に関連付ける IAM ロールを選択します。この環境に割り当てられたワークフローアクションはこの IAM ロールを継承し、これを使用してのサービスとリソースに接続できます AWS アカウント。デフォルトとして使用する IAM ロールが表示されていない場合は、まだ AWS アカウント接続に追加していない可能性があります。アカウント接続に IAM ロールを追加するには、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。 # アクションの IAM ロールの変更デフォルトでは、[[環境]](deploy-environments.md) をワークフロー[アクション](workflows-actions.md)に関連付けると、アクションは環境で指定されたデフォルトの IAM ロールを継承します。この動作は、アクションが別のロールを使用するように変更できます。デフォルトの IAM ロールに、アクションが AWS クラウドで動作するために必要なアクセス許可がない場合、アクションに別のロールを使用させる場合があります。アクションに別の IAM ロールを割り当てるには、ビジュアルエディタで **[ロールの切り替え]** オプションを使用するか、YAML エディタで `Connections:` プロパティを使用します。新しいロールは、環境で指定されたデフォルトの IAM ロールを上書きし、デフォルトの IAM ロールをそのまま保持できます。デフォルトの IAM ロールを使用する他のアクションがある場合は、そのままにしておくことをお勧めします。以下の手順に従って、環境内で指定されたロールとは異なる IAM ロールを使用するようにアクションを設定します。 ------ #### [ Visual ] **アクションに別の IAM ロールを割り当てるには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. 更新する IAM ロールのアクションを表すボックスを選択します。 1. **[設定]** タブを選択します。 1. 「***my-environment* とは？**」ボックスで、縦楕円アイコン (![\[Ellipsis.\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/elipsis.png)) を選択します。 1. **[ロールの切り替え]** を選択します。 1. **[ロールの切り替え]** ダイアログボックスの **[IAM ロール]** ドロップダウンリストで、アクションで使用する IAM ロールを選択します。このロールは、環境内のデフォルトの IAM ロールを上書きします。使用するロールが一覧にない場合は、必ずスペースに追加してください。詳細については、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。選択したロールが、「***my-environment* とは？**」ボックスと **[ワークフローで定義済み]** に表示されます。ロールは、`Connections:` セクションのワークフロー定義ファイルにも表示されます。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **アクションに別の IAM ロールを割り当てるには (YAML エディタ）** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 別の IAM ロールを使用するワークフローアクションで、次のような `Connections:` セクションを追加します。 ``` action-name: Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name ``` 上記のコードでは、*[account-connection-name]* を IAM ロールを含む [[アカウント接続]](ipa-connect-account.md) の名前に置き換え、*[iam-role-name]* をアクションで使用する IAM ロールの名前に置き換えます。このロールは、環境内のデフォルトの IAM ロールを上書きします。スペースにロールを追加していることを確認してください。詳細については、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。詳細については、トピック「[アクションタイプ](workflows-actions.md#workflows-actions-types)」を参照してください。このトピックには、YAML リファレンスを含む各アクションのドキュメントへのリンクが含まれています。 ------ # ワークフロー図でのアプリケーション URL の表示ワークフローでアプリケーションをデプロイする場合は、アプリケーションの URL をクリック可能なリンクとして表示するように Amazon CodeCatalyst を設定できます。このリンクは、CodeCatalyst コンソールにデプロイしたアクション内に表示されます。次のワークフロー図は、アクションの下部に表示される **[アプリを表示]** URL を示しています。 ![\[アプリ URL を表示する\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/deploy/view-app-url.png) CodeCatalyst コンソールでこの URL をクリック可能にすることで、アプリケーションのデプロイをすばやく確認できます。 **注記** アプリ URL は、**[Amazon ECS にデプロイ]** アクションではサポートされていません。この機能を有効にするには、`appurl`、または `endpointurl` を含む名前で出力変数をアクションに追加します。名前は、結合ダッシュ (`-`）、アンダースコア (`_`)、またはスペース (` `) の有無にかかわらず使用できます。文字列は大文字と小文字を区別しません。変数の値をデプロイされたアプリケーションの `http` または `https` URL に設定します。 **注記** 既存の出力変数を更新して `app url` または `endpoint url` 文字列を含める場合は、この変数へのすべての参照を更新して新しい変数名を使用します。詳細については、以下に記載される手順を参照してください。 + [AWS CDK 「デプロイ」アクションでアプリ URL を表示するには](#deploy-app-url-cdk) + [CloudFormation 「スタックのデプロイ」アクションでアプリ URL を表示するには](#deploy-app-url-cfn) + [他のすべてのアクションでアプリ URL を表示するには](#deploy-app-url-other) URL の設定が完了したら、以下の手順に従って、URL が期待どおりに表示されることを確認します。 + [アプリケーション URL が追加されたことを確認するには](#deploy-app-url-verify) **AWS CDK 「デプロイ」アクションでアプリ URL を表示するには** 1. **AWS CDK デプロイ**アクションを使用している場合は、 AWS CDK アプリケーションコードに`CfnOutput`コンストラクト (キーと値のペア) を追加します。 + キー名には、結合ダッシュ (`-`)、アンダースコア (`_`)、またはスペース (` `) の有無にかかわらず、`appurl` または `endpointurl` を含める必要があります。文字列は大文字と小文字を区別しません。 + 値は、デプロイされたアプリケーションの `http` または `https` URL である必要があります。たとえば、 AWS CDK コードは次のようになります。 ``` import { Duration, Stack, StackProps, CfnOutput, RemovalPolicy} from 'aws-cdk-lib'; import * as dynamodb from 'aws-cdk-lib/aws-dynamodb'; import * as s3 from 'aws-cdk-lib/aws-s3'; import { Construct } from 'constructs'; import * as cdk from 'aws-cdk-lib'; export class HelloCdkStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', { removalPolicy: RemovalPolicy.DESTROY, }); new CfnOutput(this, 'APP-URL', { value: https://mycompany.myapp.com, description: 'The URL of the deployed application', exportName: 'myApp', }); ... } } ``` `CfnOutput` コンストラクトの詳細については、「*AWS Cloud Development Kit (AWS CDK) API リファレンス*」の「[インターフェイス CfnOutputProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CfnOutputProps.html)」を参照してください。 1. コードを保存してコミットします。 1. [アプリケーション URL が追加されたことを確認するには](#deploy-app-url-verify) に進みます。 **CloudFormation 「スタックのデプロイ」アクションでアプリ URL を表示するには** 1. ** CloudFormation スタックのデプロイ**アクションを使用している場合は、CloudFormation テンプレートまたは AWS SAM テンプレートの `Outputs`セクションに、次の特性を持つ出力を追加します。 + キー (ロジカル ID とも呼ばれます) には、結合ダッシュ (`-`)、アンダースコア (`_`)、またはスペース (` `) の有無にかかわらず、`appurl` または `endpointurl` を含める必要があります。文字列は大文字と小文字を区別しません。 + 値は、デプロイされたアプリケーションの `http` または `https` URL である必要があります。例えば、CloudFormation テンプレートは次のようになります。 ``` "Outputs" : { "APP-URL" : { "Description" : "The URL of the deployed app", "Value" : "https://mycompany.myapp.com", "Export" : { "Name" : "My App" } } } ``` CloudFormation の詳細については、「*AWS CloudFormation ユーザーガイド*」の「[出力](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html)」を参照してください。 1. コードを保存してコミットします。 1. [アプリケーション URL が追加されたことを確認するには](#deploy-app-url-verify) に進みます。 **他のすべてのアクションでアプリ URL を表示するには** ビルドアクションや **[GitHub アクション]** などの別のアクションを使用してアプリケーションをデプロイする場合は、次の操作を実行してアプリケーション URL を表示します。 1. ワークフロー定義ファイルのアクションの `Inputs` または `Steps` セクションで環境変数を定義します。変数には次の特性が必要です。 + `name` には、結合ダッシュ (`-`)、アンダースコア (`_`)、またはスペース (` `) の有無にかかわらず、`appurl` または `endpointurl` を含める必要があります。文字列は大文字と小文字を区別しません。 + 値は、デプロイされたアプリケーションの `http` または `https` URL である必要があります。例えば、ビルドアクションは次のようになります。 ``` Build-action: Identifier: aws/build@v1 Inputs: Variables: - Name: APP-URL Value: https://mycompany.myapp.com ``` または、次のようになります。 ``` Actions: Build: Identifier: aws/build@v1 Configuration: Steps: - Run: APP-URL=https://mycompany.myapp.com ``` 定義環境変数の詳細については、「[変数の定義](workflows-working-with-variables-define-input.md)」を参照してください。 1. 変数をエクスポートします。例えば、ビルドアクションは次のようになります。 ``` Build-action: ... Outputs: Variables: - APP-URL ``` エクスポート変数の詳細については、「[他のアクションで使用できるように変数をエクスポートする](workflows-working-with-variables-export-input.md)」を参照してください。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 1. [アプリケーション URL が追加されたことを確認するには](#deploy-app-url-verify) に進みます。 **アプリケーション URL が追加されたことを確認するには** + 自動的に開始していない場合は、ワークフローの実行を開始します。新しい実行では、ワークフロー図にクリック可能なリンクとしてアプリケーション URL が表示される必要があります。実行開始の詳細については、「[手動でのワークフロー実行の開始](workflows-manually-start.md)」を参照してください。 # デプロイターゲットの削除 Amazon ECS クラスターや CloudFormation スタックなどのデプロイターゲットは、CodeCatalyst コンソールの**デプロイターゲット**ページから削除できます。 **重要** デプロイターゲットを削除すると、CodeCatalyst コンソールから削除されますが、それをホストする AWS サービスで引き続き使用できます (まだ存在する場合）。 CodeCatalyst でターゲットが古くなった場合は、デプロイターゲットの削除を検討してください。次の場合、ターゲットは古くなる可能性があります。 + ターゲットにデプロイされたワークフローを削除しました。 + デプロイ先のスタックまたはクラスターを変更しました。 + AWS コンソールの CloudFormation または Amazon ECS サービスからスタックまたはクラスターを削除しました。 **デプロイターゲットを削除するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。 1. 削除するデプロイターゲットを含む環境の名前を選択します。環境の詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」を参照してください。 1. **[デプロイ]** タブを選択します。 1. 削除するデプロイターゲットの横にあるラジオボタンを選択します。 1. **[**を削除] を選択します。ターゲットはページから削除されます。 # コミット別のデプロイステータスの追跡開発ライフサイクルのいずれの時点でも、バグ修正、新機能、およびその他に影響を及ぼす変更など、特定のコミットのデプロイステータスを把握することが重要です。開発チームにとってデプロイステータスの追跡機能が役立つシナリオとして、次の例を考えます。 + デベロッパーとして、バグの修正を行い、チームのデプロイ環境全体にわたるデプロイのステータスを報告する必要がある。 + リリースマネージャーとして、デプロイされたコミットのリストを表示し、デプロイのステータスを追跡および報告する必要がある。 CodeCatalyst には、個々のコミットまたは変更がどの場所にデプロイされたか、そしてどの環境にデプロイされたかを一目で確認できるビューが用意されています。このビューには以下が含まれます。 + コミットのリスト。 + コミットに対応するデプロイのステータス。 + コミットが正常にデプロイされた環境。 + CI/CD ワークフローでのコミットに対するテスト実行のステータス。次の手順では、このビューに移動し、このビューを使用してプロジェクトの変更を追跡する方法について説明します。 **注記** コミット別のデプロイステータスの追跡は、[CodeCatalyst リポジトリ](source.md)でのみサポートされています。この機能は、[GitHub リポジトリ、Bitbucket リポジトリ、または GitLab プロジェクトリポジトリ](extensions.md)では使用できません。 **コミット別にデプロイステータスを追跡するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]** を選択し、**[追跡変更]** を選択します。 1. メインペインの上部にある 2 つのドロップダウンリストで、リリースステータスを表示するコミットが含まれたソースリポジトリおよびソースブランチを選択します。 1. **[変更を表示]** を選択します。コミットのリストが表示されます。コミットごとに、以下を表示できます。 + ID、作成者、メッセージ、コミット日時などのコミット情報。詳細については、「[CodeCatalyst のソースリポジトリでコードを保存し、共同作業を行うソースリポジトリでコードを保存して共同作業を行う](source.md)」を参照してください。 + 各環境へのデプロイのステータス。詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」を参照してください。 + テストとコードカバレッジの結果。詳細については、「[ワークフローを使用したテストワークフローを使用したテスト](test-workflow-actions.md)」を参照してください。 **注記** ソフトウェア構成分析 (SCA) の結果は表示されません。 1. (オプション) 最新のデプロイ、詳細なコードカバレッジ、ユニットテスト情報など、特定のコミットに関連する変更の詳細を表示するには、そのコミットの **[詳細を表示]** を選択します。 # デプロイログの表示特定のデプロイアクションに関連するログを表示して、Amazon CodeCatalyst の問題をトラブルシューティングできます。 [[ワークフロー]](workflow.md) または [[環境]](deploy-environments.md) からログを表示できます。 **ワークフローから開始するデプロイアクションのログを表示するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[実行]** を選択します。 1. アプリケーションをデプロイしたワークフロー実行を選択します。 1. ワークフロー図で、ログを表示するアクションを選択します。 1. **[ログ]** タブを選択し、セクションを展開してログメッセージを表示します。 1. その他のログを表示するには、**[概要]** タブを選択し、**[CloudFormation で表示]** (利用可能な場合) を選択して、その他のログを表示します。 AWSにサインインする必要がある場合があります。 **環境から開始するデプロイアクションのログを表示するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。 1. アプリケーションがデプロイされた環境を選択します。 1. **[デプロイアクティビティ]** で、**[ワークフロー実行 ID]** 列を見つけ、スタックをデプロイしたワークフロー実行を選択します。 1. ワークフロー図で、ログを表示するアクションを選択します。 1. **[ログ]** タブを選択し、セクションを展開してログメッセージを表示します。 1. その他のログを表示するには、**[概要]** タブを選択し、**[CloudFormation で表示]** (利用可能な場合) を選択して、その他のログを表示します。 AWSにサインインする必要がある場合があります。 # デプロイ情報の表示 Amazon CodeCatalyst のデプロイに関する以下の情報を表示できます。 + デプロイステータス、開始時刻、終了時刻、履歴、イベントの所要時間を含むデプロイアクティビティ。 + スタック名 AWS リージョン、最終更新時刻、および関連するワークフロー。 + リクエストをコミットしてプルします。 + CloudFormation イベントや出力などのアクション固有の情報。 [[ワークフロー]](workflow.md)、[[環境]](deploy-environments.md)、またはワークフロー [[アクション]](workflows-concepts.md#workflows-concepts-actions) からデプロイ情報を表示できます。 **ワークフローからデプロイ情報を表示するには** + アプリケーションをデプロイしたワークフロー実行に移動します。手順については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。 **環境からデプロイ情報を表示するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで、**[CI/CD]**、**[環境]** の順に選択します。 1. スタックがデプロイされた環境を選択します。例: `Production`。 1. **[デプロイアクティビティ]** を選択して、スタックのデプロイ履歴、デプロイのステータス (**[成功]** や **[失敗]** など)、およびその他のデプロイ関連情報を表示します。 1. **[デプロイターゲット]** を選択すると、環境にデプロイされたスタック、クラスター、またはその他のターゲットに関する情報が表示されます。スタック名、リージョン、プロバイダー、識別子などの情報を表示できます。 **アクションからデプロイ情報を表示するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. ワークフロー図で、アプリケーションをデプロイしたワークフローアクションを選択します。例えば、**[DeployCloudFormationStack]** を選択できます。 1. アクション固有のデプロイ情報については、右側のペインの内容を確認してください。 # ワークフローの作成 *ワークフロー*は、継続的統合と継続的配信 (CI/CD) システムの一部としてコードを構築、テスト、デプロイする方法を説明する自動手順です。ワークフローは、ワークフローの実行中に実行する一連のステップまたは*アクション*を定義します。ワークフローは、ワークフローを開始するイベント、または*トリガー*も定義します。ワークフローを設定するには、CodeCatalyst コンソールの[ビジュアルエディタまたは YAML エディタ](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors)を使用して*ワークフロー定義ファイル*を作成します。 **ヒント** プロジェクトでワークフローを使用する方法を簡単に確認するには、[ブループリントを使用してプロジェクトを作成](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template)します。各ブループリントは、レビュー、実行、実験可能な機能するワークフローをデプロイします。 CodeCatalyst でワークフローを作成するには、次の手順に従います。ワークフローは、選択したソースリポジトリの `~/.codecatalyst/workflows/` フォルダに YAML ファイルとして保存されます。必要に応じて、コミット時にワークフローファイル名の前にフォルダ名を付けることで、ワークフローを `~/.codecatalyst/workflows/` のサブフォルダに保存できます。詳細については、以降の手順を参照してください。ワークフローの詳細については、「[ワークフローを使用して構築、テスト、デプロイするワークフローを使用して構築、テスト、デプロイする](workflow.md)」を参照してください。 ------ #### [ Visual ] **ビジュアルエディタを使用してワークフローを作成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフローを作成]** を選択します。 **[ワークフローを作成]** ダイアログボックスが表示されます。 1. **[ソースリポジトリ]** フィールドで、ワークフロー定義ファイルを配置するソースリポジトリを選択します。ソースリポジトリが存在しない場合は[作成](source-repositories-create.md)してください。 1. **[ブランチ]** フィールドで、ワークフロー定義ファイルを配置するブランチを選択します。 1. **[作成]** を選択します。 Amazon CodeCatalyst ではリポジトリとブランチの情報をメモリに保存しますが、ワークフローはまだコミットされていません。 1. **[ビジュアル]** を選択します。 1. ワークフローを構築します。 1. (省略可) ワークフロー図で、**[ソース]** ボックスと **[トリガー]** ボックスを選択します。**[トリガー]** ペインが表示されます。**[トリガーを追加]** を選択してトリガーを追加します。詳細については、「[ワークフローへのトリガーの追加](workflows-add-trigger-add.md)」を参照してください。 1. 左上の **[\$1 アクション]** を選択します。**[アクション]** カタログが表示されます。 1. アクション内のプラス記号 (**\$1**) を選択して、ワークフローに追加します。右側のペインを使用してアクションを構成します。詳細については、「[ワークフローへのアクションの追加](workflows-add-action.md)」を参照してください。 1. (省略可) **[ワークフローのプロパティ]** (右上) を選択します。**[ワークフローのプロパティ]** ペインが表示されます。ワークフロー名、実行モード、コンピューティングを構成します。詳細については、「[実行のキュー動作の構成](workflows-configure-runs.md)」および「[コンピューティングイメージとランタイムイメージの構成](workflows-working-compute.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、**[ワークフローをコミット]** ダイアログボックスで以下を実行します。 1. **[ワークフローファイル名]** では、デフォルト名のままにするか名前を入力します。選択したソースリポジトリとブランチの `~/.codecatalyst/workflows/` フォルダにファイルが保存されます。ファイル名には、フォルダまたはサブフォルダを先頭に付けることができます。例: + `my-workflow` (フォルダなし) を指定するとファイルが `~/.codecatalyst/workflows/my-workflow.yaml` として保存される + `folder/subfolder/my-workflow` を指定するとファイルが `~/.codecatalyst/workflows/folder/subfolder/my-workflow.yaml` として保存される 1. **[メッセージをコミット]** では、デフォルトメッセージのままにするかメッセージを入力します。 1. **[リポジトリ]** と **[ブランチ]** では、ワークフロー定義ファイルのソースリポジトリとブランチを選択します。これらのフィールドは、**[ワークフローを作成]** ダイアログボックスでさきほど指定したリポジトリとブランチに設定する必要があります。必要に応じて、リポジトリとブランチをこのタイミングで変更できます。 **注記** ワークフロー定義ファイルをコミットした後は、別のリポジトリやブランチに関連付けることはできません。必ず慎重に選択してください。 1. **[コミット]** を選択してワークフロー定義ファイルをコミットします。 ------ #### [ YAML ] **YAML エディタを使用してワークフローを作成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフローを作成]** を選択します。 **[ワークフローを作成]** ダイアログボックスが表示されます。 1. **[ソースリポジトリ]** フィールドで、ワークフロー定義ファイルを配置するソースリポジトリを選択します。ソースリポジトリが存在しない場合は[作成](source-repositories-create.md)してください。 1. **[ブランチ]** フィールドで、ワークフロー定義ファイルを配置するブランチを選択します。 1. **[作成]** を選択します。 Amazon CodeCatalyst ではリポジトリとブランチの情報をメモリに保存しますが、ワークフローはまだコミットされていません。 1. **[YAML]** を選択します。 1. ワークフローを構築します。 1. (省略可) YAML コードにトリガーを追加します。詳細については、「[ワークフローへのトリガーの追加](workflows-add-trigger-add.md)」を参照してください。 1. 左上の **[\$1 アクション]** を選択します。**[アクション]** カタログが表示されます。 1. アクション内のプラス記号 (**\$1**) を選択して、ワークフローに追加します。右側のペインを使用してアクションを構成します。詳細については、「[ワークフローへのアクションの追加](workflows-add-action.md)」を参照してください。 1. (省略可) **[ワークフローのプロパティ]** (右上) を選択します。**[ワークフローのプロパティ]** ペインが表示されます。ワークフロー名、実行モード、コンピューティングを構成します。詳細については、「[実行のキュー動作の構成](workflows-configure-runs.md)」および「[コンピューティングイメージとランタイムイメージの構成](workflows-working-compute.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、**[ワークフローをコミット]** ダイアログボックスで以下を実行します。 1. **[ワークフローファイル名]** では、デフォルト名のままにするか名前を入力します。選択したソースリポジトリとブランチの `~/.codecatalyst/workflows/` フォルダにファイルが保存されます。ファイル名には、フォルダまたはサブフォルダを先頭に付けることができます。例: + `my-workflow` (フォルダなし) を指定するとファイルが `~/.codecatalyst/workflows/my-workflow.yaml` として保存される + `folder/subfolder/my-workflow` を指定するとファイルが `~/.codecatalyst/workflows/folder/subfolder/my-workflow.yaml` として保存される 1. **[メッセージをコミット]** では、デフォルトメッセージのままにするかメッセージを入力します。 1. **[リポジトリ]** と **[ブランチ]** では、ワークフロー定義ファイルのソースリポジトリとブランチを選択します。これらのフィールドは、**[ワークフローを作成]** ダイアログボックスでさきほど指定したリポジトリとブランチに設定する必要があります。必要に応じて、リポジトリとブランチをこのタイミングで変更できます。 **注記** ワークフロー定義ファイルをコミットした後は、別のリポジトリやブランチに関連付けることはできません。必ず慎重に選択してください。 1. **[コミット]** を選択してワークフロー定義ファイルをコミットします。 ------ # ワークフローの実行 *実行*はワークフローの 1 回の反復です。実行中、CodeCatalyst ではワークフロー構成ファイルで定義されているアクションを実行し、関連するログ、アーティファクト、変数を出力します。 *ワークフロートリガー*を使用して、手動で実行を開始することも、自動的に実行を開始することもできます。ワークフロートリガーの例として、コミットをメインブランチにプッシュするソフトウェアデベロッパーなどが挙げられます。誤ってワークフロー実行を開始した場合は、処理の途中でワークフロー実行を手動で停止することもできます。複数のワークフロー実行がほぼ同時に開始される場合は、これらの実行をキューに入れる方法を構成できます。デフォルトのキュー動作を使用できます。デフォルトでは、開始された順序で順番に実行がキューに入れられます。前の実行よりも後続の実行を優先 (または「引き継ぎ」) させて、全体の実行を高速化することもできます。ワークフロー実行を並列で実行するように設定して、ある実行が他の実行を待たなくて済むようにすることも可能です。ワークフロー実行を手動または自動で開始すると、実行のステータスやその他の詳細を確認できます。例えば、いつ開始されたか、誰によって開始されたか、まだ実行されているかどうかを確認できます。 **Topics** + [ # 手動でのワークフロー実行の開始 ](workflows-manually-start.md) + [ # トリガーを使用したワークフロー実行の自動的な開始 ](workflows-add-trigger.md) + [ # 手動専用トリガーの構成 ](workflows-manual-only.md) + [ # ワークフロー実行の停止 ](workflows-stop.md) + [ # ゲートを使用したワークフロー実行の続行防止 ](workflows-gates.md) + [ # ワークフロー実行の承認の必須化 ](workflows-approval.md) + [ # 実行のキュー動作の構成 ](workflows-configure-runs.md) + [ # ワークフロー実行間のファイルのキャッシュ ](workflows-caching.md) + [ # ワークフロー実行のステータスと詳細の表示 ](workflows-view-run.md) # 手動でのワークフロー実行の開始 Amazon CodeCatalyst では、CodeCatalyst コンソールから手動でワークフロー実行を開始できます。ワークフロー実行の詳細については、「[ワークフローの実行](workflows-working-runs.md)」を参照してください。 **注記** [トリガーを構成](workflows-add-trigger.md)することで、ワークフロー実行を自動的に開始することもできます。 **ワークフロー実行を手動で開始するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[Run]** (実行) を選択します。 # トリガーを使用したワークフロー実行の自動的な開始 Amazon CodeCatalyst ワークフロー実行は、ワークフロートリガーを使用して自動的に開始できます。 *ワークフロートリガー* (または単に*トリガー*) を使用すると、コードプッシュなどの特定のイベントが発生したときにワークフロー実行を自動的に開始できます。ソフトウェアデベロッパーが CodeCatalyst コンソールを使用してワークフロー実行を手動で開始する必要がないようにトリガーを構成することもできます。次の 3 種類のトリガーを使用できます。 + **プッシュ** – コードプッシュトリガーにより、コミットがプッシュされるたびにワークフロー実行が開始されます。 + **プルリクエスト** – プルリクエストトリガーにより、プルリクエストが作成、改訂、またはクローズされるたびにワークフロー実行が開始されます。 + **スケジュール** – スケジュールトリガーにより、定義したスケジュールに沿ってワークフロー実行が開始されます。スケジュールトリガーを使用してソフトウェアのビルドを毎晩実行し、ソフトウェアデベロッパーが翌日の朝に最新ビルドで作業できるようにすることを検討してください。プッシュ、プルリクエスト、スケジュールの各トリガーは単独で使用することも、同じワークフロー内で組み合わせて使用することもできます。トリガーは必須ではありません。トリガーを構成しない場合はワークフローを手動で開始する必要があります。 **ヒント** トリガーを実際に試すには、ブループリントがあるプロジェクトを起動します。ほとんどのブループリントにはトリガー付きのワークフローが含まれています。ブループリントのワークフロー定義ファイルで `Trigger` プロパティを探します。設計図の詳細については、「[ブループリントを使用したプロジェクトの作成](projects-create.md#projects-create-console-template)」を参照してください。 **Topics** + [ # 例: ワークフローのトリガー ](workflows-add-trigger-examples.md) + [ # トリガーとブランチの使用ガイドライン ](workflows-add-trigger-considerations.md) + [ # ワークフローへのトリガーの追加 ](workflows-add-trigger-add.md) # 例: ワークフローのトリガー次の例は、Amazon CodeCatalyst ワークフロー定義ファイルにさまざまなタイプのトリガーを追加する方法を示したものです。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 **Topics** + [ ## 例: シンプルなコードプッシュトリガー ](#workflows-add-trigger-examples-push-simple) + [ ## 例: シンプルな「メインへのプッシュ」トリガー ](#workflows-add-trigger-examples-push-main) + [ ## 例: シンプルなプルリクエストトリガー ](#workflows-add-trigger-examples-pull-simple) + [ ## 例: シンプルなスケジュールトリガー ](#workflows-add-trigger-examples-schedule-simple) + [ ## 例: スケジュールとブランチを含むトリガー ](#workflows-add-trigger-examples-schedule-branches) + [ ## 例: スケジュール、プッシュ、ブランチを含むトリガー ](#workflows-add-trigger-examples-schedule-push-branches) + [ ## 例: プルとブランチを含むトリガー ](#workflows-add-trigger-examples-pull-branches) + [ ## 例: プル、ブランチ、および「CLOSED」イベントを含むトリガー ](#workflows-add-trigger-examples-push-pull-close) + [ ## 例: プッシュ、ブランチ、ファイルを含むトリガー ](#workflows-add-trigger-examples-push-multi) + [ ## 例: 手動トリガー ](#workflows-add-trigger-examples-manual) + [ ## 例: CI/CD マルチワークフロー設定のトリガー ](#workflows-add-trigger-usecases) ## 例: シンプルなコードプッシュトリガー次の例は、ソースリポジトリ内の*いずれかの*ブランチにコードがプッシュされるたびにワークフロー実行を開始するトリガーを示したものです。このトリガーがアクティブ化されると、CodeCatalyst ではプッシュ*先*のブランチ (つまり、送信先ブランチ) 内のファイルを使用してワークフロー実行を開始します。例えば、コミットを `main` にプッシュすると、CodeCatalyst では `main` のワークフロー定義ファイルやその他のソースファイルを使用してワークフロー実行を開始します。別の例として、コミットを `feature-branch-123` にプッシュすると、CodeCatalyst では `feature-branch-123` のワークフロー定義ファイルやその他のソースファイルを使用してワークフロー実行を開始します。 ``` Triggers: - Type: PUSH ``` **注記** `main` にプッシュした場合にのみワークフロー実行を開始する場合は、「[例: シンプルな「メインへのプッシュ」トリガー](#workflows-add-trigger-examples-push-main)」を参照してください。 ## 例: シンプルな「メインへのプッシュ」トリガー次の例は、ソースリポジトリ内の `main` ブランチ (および `main` ブランチ*のみ*) にコードがプッシュされるたびにワークフロー実行を開始するトリガーを示したものです。 ``` Triggers: - Type: PUSH Branches: - main ``` ## 例: シンプルなプルリクエストトリガー次の例は、ソースリポジトリ内でプルリクエストが作成または改訂されるたびにワークフロー実行を開始するトリガーを示したものです。このトリガーがアクティブ化されると、CodeCatalyst ではプル*元*のブランチ (つまり、ソースブランチ) 内のワークフロー定義ファイルやその他のソースファイルを使用してワークフロー実行を開始します。例えば、`feature-123` というソースブランチと `main` という宛先ブランチを使用してプルリクエストを作成すると、CodeCatalyst では `feature-123` のワークフロー定義ファイルやその他のソースファイルを使用してワークフロー実行を開始します。 ``` Triggers: - Type: PULLREQUEST Events: - OPEN - REVISION ``` ## 例: シンプルなスケジュールトリガー次の例は、毎週月曜日から金曜日の午前 0 時 (UTC\$10) にワークフロー実行を開始するトリガーを示したものです。このトリガーがアクティブ化されると、CodeCatalyst では、このトリガーがあるワークフロー定義ファイルを含むソースリポジトリ内のブランチごとに 1 つのワークフロー実行を開始します。例えば、ソースリポジトリに `main`、`release-v1`、`feature-123` という 3 つのブランチがあり、後続トリガーがあるワークフロー定義ファイルがこれらの各ブランチに含まれている場合、CodeCatalyst では 3 つのワークフロー実行を開始します。1 つ目のワークフロー実行では `main` のファイル、2 つ目のワークフロー実行では `release-v1` のファイル、3 つ目のワークフロー実行では `feature-123` のファイルを使用します。 ``` Triggers: - Type: SCHEDULE Expression: "0 0 ? * MON-FRI *" ``` `Expression` プロパティで使用できる cron 式のその他の例については、「[Expression](workflow-reference.md#workflow.triggers.expression)」を参照してください。 ## 例: スケジュールとブランチを含むトリガー次の例は、毎日午後 6 時 15 分 (UTC\$10) にワークフロー実行を開始するトリガーを示したものです。このトリガーがアクティブ化されると、CodeCatalyst では `main` ブランチ内のファイルを使用してワークフロー実行を開始し、`release-` で始まるブランチごとに追加の実行を開始します。例えば、ソースリポジトリに `main`、`release-v1`、`bugfix-1`、`bugfix-2` という名前のブランチがある場合、CodeCatalyst では 2 つのワークフロー実行を開始します。1 つ目のワークフロー実行では `main` のファイル、2 つ目のワークフロー実行では `release-v1` のファイルを使用します。`bugfix-1` ブランチと `bugfix-1` ブランチのワークフロー実行は開始*されません*。 ``` Triggers: - Type: SCHEDULE Expression: "15 18 * * ? *" Branches: - main - release\-.* ``` `Expression` プロパティで使用できる cron 式のその他の例については、「[Expression](workflow-reference.md#workflow.triggers.expression)」を参照してください。 ## 例: スケジュール、プッシュ、ブランチを含むトリガー次の例は、毎日午前 0 時 (UTC\$10) に、コードが `main` ブランチにプッシュされるたびにワークフロー実行を開始するトリガーを示したものです。この例では、以下のようになっています： + ワークフロー実行は毎日午前 0 時に開始されます。ワークフロー実行では、`main` ブランチ内のワークフロー定義ファイルとその他のソースファイルを使用します。 + コミットを `main` ブランチにプッシュするたびにもワークフロー実行が開始されます。ワークフロー実行では、宛先ブランチ (`main`) 内のワークフロー定義ファイルとその他のソースファイルを使用します。 ``` Triggers: - Type: SCHEDULE Expression: "0 0 * * ? *" Branches: - main - Type: PUSH Branches: - main ``` `Expression` プロパティで使用できる cron 式のその他の例については、「[Expression](workflow-reference.md#workflow.triggers.expression)」を参照してください。 ## 例: プルとブランチを含むトリガー次の例は、誰かが `main` という宛先ブランチでプルリクエストを開いたり変更したりするたびにワークフロー実行を開始するトリガーを示したものです。`Triggers` 構成で指定されているブランチは `main` ですが、ワークフロー実行では、*ソース*ブランチ (プル*元*のブランチ) 内のワークフロー定義ファイルとその他のソースファイルが使用されます。 ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION ``` ## 例: プル、ブランチ、および「CLOSED」イベントを含むトリガー次の例は、`main` で始まるブランチでプルリクエストを閉じるたびにワークフロー実行を開始するトリガーを示したものです。この例では、以下のようになっています： + `main` で始まる宛先ブランチでプルリクエストを閉じると、(閉じたばかりの) ソースブランチのワークフロー定義ファイルとその他のソースファイルを使用して、ワークフロー実行が自動的に開始されます。 + プルリクエストがマージされた後にブランチを自動的に削除するようにソースリポジトリを構成している場合、これらのブランチが `CLOSED` 状態になることはありません。つまり、マージされたブランチはプルリクエスト `CLOSED` トリガーをアクティブ化しません。このシナリオで `CLOSED` トリガーをアクティブ化する唯一の方法は、プルリクエストをマージせずに閉じることです。 ``` Triggers: - Type: PULLREQUEST Branches: - main.* Events: - CLOSED ``` ## 例: プッシュ、ブランチ、ファイルを含むトリガー次の例は、`main` ブランチの `filename.txt` ファイルまたは `src` ディレクトリ内のファイルに変更が加えられるたびにワークフロー実行を開始するトリガーを示したものです。このトリガーがアクティブ化されると、CodeCatalyst では `main` ブランチのワークフロー定義ファイルとその他のソースファイルを使用してワークフロー実行を開始します。 ``` Triggers: - Type: PUSH Branches: - main FilesChanged: - filename.txt - src\/.* ``` ## 例: 手動トリガー手動トリガーを構成するには、ワークフロー定義ファイルから `Triggers` セクションを省略します。このセクションがない場合、ユーザーは CodeCatalyst コンソールで **[実行]** ボタンを選択してワークフローを手動で開始する必要があります。詳細については、「[手動でのワークフロー実行の開始](workflows-manually-start.md)」を参照してください。 ## 例: CI/CD マルチワークフロー設定のトリガーこの例では、継続的インテグレーション (CI) と継続的デプロイ (CD) でそれぞれ別の Amazon CodeCatalyst ワークフローを使用する場合にトリガーを設定する方法について説明します。このシナリオでは、次の 2 つのワークフローを設定します。 + **CI ワークフロー** – このワークフローでは、プルリクエストが作成または改訂されたときにアプリケーションをビルドしてテストします。 + **CD ワークフロー** – このワークフローでは、プルリクエストがマージされたときにアプリケーションをビルドしてデプロイします。 **CI ワークフロー**の定義ファイルの内容は次のようになります。 ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION Actions: BuildAction: instructions-for-building-the-app TestAction: instructions-for-test-the-app ``` `Triggers` コードは、フィーチャーブランチを `main` ブランチにマージするように求めるプルリクエストをソフトウェアデベロッパーが作成 (または[変更](pull-requests-update.md)) するたびに、ワークフロー実行を自動的に開始することを示しています。CodeCatalyst では、ソースブランチ (フィーチャーブランチ) のソースコードを使用してワークフロー実行を開始します。 **CD ワークフロー**の定義ファイルの内容は次のようになります。 ``` Triggers: - Type: PUSH Branches: - main Actions: BuildAction: instructions-for-building-the-app DeployAction: instructions-for-deploying-the-app ``` `Triggers` コードは、`main` へのマージが発生したときにワークフローを自動的に開始することを示しています。CodeCatalyst では、`main` ブランチのソースコードを使用してワークフロー実行を開始します。 # トリガーとブランチの使用ガイドラインこのセクションでは、ブランチを含む Amazon CodeCatalyst トリガーを設定する際の主なガイドラインについて説明します。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + **ガイドライン 1:** プッシュリクエストトリガーとプルリクエストトリガーの両方について、ブランチを指定する場合は、トリガー構成で宛先 (または送信先) ブランチを指定する必要があります。ソース (または「送信元」) ブランチを指定しないでください。次の例では、任意のブランチから `main` へのプッシュがワークフローをアクティブ化しています。 ``` Triggers: - Type: PUSH Branches: - main ``` 次の例では、任意のブランチから `main` へのプルリクエストがワークフローをアクティブ化しています。 ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION ``` + **ガイドライン 2:** プッシュトリガーの場合、ワークフローがアクティブ化されると、*宛先*ブランチのワークフロー定義ファイルとソースファイルを使用してワークフローが実行されます。 + **ガイドライン 3:** プルリクエストトリガーの場合、ワークフローがアクティブ化されると、*ソース*ブランチのワークフロー定義ファイルとソースファイルを使用してワークフローが実行されます (トリガー構成で宛先ブランチを指定している場合でも)。 + **ガイドライン 4:** あるブランチのまったく同じトリガーが別のブランチでは実行されない場合があります。次のプッシュトリガーを検討してください。 ``` Triggers: - Type: PUSH Branches: - main ``` このトリガーを含むワークフロー定義ファイルが `main` に存在し、`test` にクローンされる場合、`test` のファイルを使用して自動的にワークフローが開始されることはありません (ただし、ワークフローを*手動*で開始して `test` のファイルを使用するようにすることは可能)。`test` のファイルを使用してワークフローが自動的に実行されない理由については、**ガイドライン 2** を参照してください。次のプルリクエストトリガーも検討してください。 ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION ``` このトリガーを含むワークフロー定義ファイルが `main` に存在する場合、`main` のファイルを使用してワークフローが実行されることはありません (ただし、`main` から `test` ブランチを作成すると、`test` のファイルを使用してワークフローが実行されます)。その理由については**ガイドライン 3** を参照してください。 # ワークフローへのトリガーの追加 Amazon CodeCatalyst ワークフローにプッシュ、プル、またはスケジュールのトリガーを追加するには、次の手順に従います。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 ------ #### [ Visual ] **トリガーを追加するには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、**[ソース]** ボックスと **[トリガー]** ボックスを選択します。 1. 構成ペインで **[トリガーを追加]** を選択します。 1. **[トリガーを追加]** ダイアログボックスで、次のようにフィールドに情報を入力します。 **トリガータイプ** トリガーのタイプを指定します。次のいずれかの値を使用できます。 + **プッシュ** (ビジュアルエディタ) または `PUSH` (YAML エディタ）プッシュトリガーでは、変更がソースリポジトリにプッシュされたときにワークフロー実行を開始します。ワークフロー実行では、プッシュ*先*のブランチ (つまり、送信先ブランチ) 内のファイルが使用されます。 + **プルリクエスト** (ビジュアルエディタ) または `PULLREQUEST` (YAML エディタ）プルリクエストトリガーでは、プルリクエストがソースリポジトリでオープン、更新、またはクローズされたときにワークフロー実行を開始します。ワークフロー実行では、プル*元*のブランチ (つまり、送信元ブランチ) 内のファイルが使用されます。 + **スケジュール** (ビジュアルエディタ) または `SCHEDULE` (YAML エディタ）スケジュールトリガーでは、指定した cron 式で定義されているスケジュールに従ってワークフロー実行を開始します。ブランチのファイルを使用して、ソースリポジトリ内のブランチごとに個別のワークフロー実行が開始されます (トリガーがアクティブ化するブランチを制限するには、**[ブランチ]** フィールド (ビジュアルエディタ) または `Branches` プロパティ (YAML エディタ) を使用します)。スケジュールトリガーを構成するときは、次のガイドラインに従ってください。 + ワークフロー 1 つにつきスケジュールトリガーを 1 つだけ使用してください。 + CodeCatalyst スペース内で複数のワークフローを定義している場合は、同時に開始するようスケジュールするワークフローは 10 個までにすることをお勧めします。 + トリガーの cron 式を設定する際は、実行間隔に十分な時間を確保してください。詳細については、「[Expression](workflow-reference.md#workflow.triggers.expression)」を参照してください。例については「[例: ワークフローのトリガー](workflows-add-trigger-examples.md)」を参照してください。 **プルリクエストのイベント** **[プルリクエスト]** トリガータイプを選択した場合のみこのフィールドが表示されます。ワークフロー実行を開始するプルリクエストイベントのタイプを指定します。有効な値を次に示します。 + **プルリクエストが作成されました** (ビジュアルエディタ) または `OPEN` (YAML エディタ）プルリクエストが作成されるとワークフロー実行が開始されます。 + **プルリクエストはクローズされました** (ビジュアルエディタ) または `CLOSED` (YAML エディタ）プルリクエストがクローズされるとワークフロー実行が開始されます。`CLOSED` イベントの動作は理解が難しいため、例を見ることで最もよく理解できます。詳細については「[例: プル、ブランチ、および「CLOSED」イベントを含むトリガー](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close)」を参照してください。 + **プルリクエストに対して新しいリビジョンが作成されます** (ビジュアルエディタ) または `REVISION` (YAML エディタ) プルリクエストに対してリビジョンが作成されるとワークフロー実行が開始されます。プルリクエストが作成されると最初のリビジョンが作成されます。その後、プルリクエストで指定されたソースブランチに新しいコミットがプッシュされるたびに、新しいリビジョンが作成されます。プルリクエストトリガーに `REVISION` イベントを含める場合、`REVISION` は `OPEN` のスーパーセットであるため、`OPEN` イベントは省略しても構いません。同じプルリクエストトリガー内で複数のイベントを指定できます。例については「[例: ワークフローのトリガー](workflows-add-trigger-examples.md)」を参照してください。 **スケジュール** **[スケジュール]** トリガータイプを選択した場合のみこのフィールドが表示されます。スケジュールされたワークフロー実行をいつ実行するかを記述する cron 式を指定します。 CodeCatalyst の cron 式では次の 6 フィールド構文を使用します。各フィールドはスペースで区切られます。 *分* *時間* *日* *月* *曜日* *年* **cron 式の例** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/workflows-add-trigger-add.html) CodeCatalyst で cron 式を指定する場合は、次のガイドラインに従ってください。 + `SCHEDULE` トリガー 1 つにつき cron 式を 1 つ指定してください。 + YAML エディタでは cron 式を二重引用符 (`"`) で囲んでください。 + 協定世界時 (UTC) で時間を指定します。他のタイムゾーンはサポートされていません。 + 実行間隔を 30 分以上に設定します。これより短い間隔はサポートされていません。 + *[日]* フィールドと *[曜日]* フィールドのいずれかを指定します。両方を指定することはできません。一方のフィールドに値またはアスタリスク (`*`) を指定する場合、もう一方のフィールドでは疑問符 (`?`) を使用する必要があります。アスタリスクは「すべて」を意味し、疑問符は「いずれか」を意味します。 cron 式のその他の例、および `?`、`*`、`L` などのワイルドカードの情報については、「*Amazon EventBridge ユーザーガイド*」の「[Cron expressions reference](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html)」を参照してください。EventBridge と CodeCatalyst で cron 式はまったく同じように動作します。スケジュールトリガーの例については、「[例: ワークフローのトリガー](workflows-add-trigger-examples.md)」を参照してください。 **[ブランチ]** と **[ブランチパターン]** (オプション) ワークフロー実行を開始するタイミングを把握するために、トリガーがモニタリングするソースリポジトリ内のブランチを指定します。正規表現パターンを使用してブランチ名を定義できます。例えば、`main` で始まるすべてのブランチを照合するには `main.*` を使用します。指定するブランチはトリガータイプによって異なります。 + プッシュトリガーでは、プッシュ*先*するブランチ、つまり*送信先*ブランチを指定します。一致するブランチ内のファイルを使用して、一致するブランチごとに 1 つのワークフロー実行が開始されます。例: `main.*`、`mainline` + プルリクエストトリガーでは、プッシュ*先*のブランチ、つまり*送信先*ブランチを指定します。ワークフロー定義ファイルと**ソース**ブランチ内のソースファイル (一致するブランチ*ではない*) を使用して、一致するブランチごとに 1 つのワークフロー実行が開始されます。例: `main.*`、`mainline`、`v1\-.*` (`v1-` で始まるブランチと一致) + スケジュールトリガーでは、スケジュールされた実行で使用するファイルを含むブランチを指定します。ワークフロー定義ファイルと一致するブランチ内のソースファイルを使用して、一致するブランチごとに 1 つのワークフロー実行が開始されます。例: `main.*`、`version\-1\.0` **注記** ブランチを指定*しない*場合、トリガーはソースリポジトリ内のすべてのブランチをモニタリングし、次の場所にあるワークフロー定義ファイルとソースファイルを使用してワークフロー実行を開始します。プッシュ*先*のブランチ (プッシュトリガーの場合)。詳細については、「[例: シンプルなコードプッシュトリガー](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple)」を参照してください。プル*元*のブランチ (プルリクエストトリガーの場合)。詳細については、「[例: シンプルなプルリクエストトリガー](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple)」を参照してください。すべてのブランチ (スケジュールトリガーの場合)。ソースリポジトリ内のブランチごとに 1 つのワークフロー実行が開始されます。詳細については、「[例: シンプルなスケジュールトリガー](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple)」を参照してください。ブランチとトリガーの詳細については、「[トリガーとブランチの使用ガイドライン](workflows-add-trigger-considerations.md)」を参照してください。その他の例については、「[例: ワークフローのトリガー](workflows-add-trigger-examples.md)」を参照してください。 **変更されたファイル** **[プッシュ]** または **[プルリクエスト]** トリガータイプを選択した場合のみこのフィールドが表示されます。ワークフロー実行を開始するタイミングを把握するために、トリガーがモニタリングするソースリポジトリ内のファイルかフォルダを指定します。正規表現を使用して、ファイルの名前またはパスを照合できます。例については「[例: ワークフローのトリガー](workflows-add-trigger-examples.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **トリガーを追加するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 次の例を参考にして、`Triggers` セクションとベースとなるプロパティを追加します。詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」の「[Triggers](workflow-reference.md#triggers-reference)」を参照してください。コードプッシュトリガーは次のようになります。 ``` Triggers: - Type: PUSH Branches: - main ``` プルリクエストトリガーは次のようになります。 ``` Triggers: - Type: PULLREQUEST Branches: - main.* Events: - OPEN - REVISION - CLOSED ``` スケジュールトリガーは次のようになります。 ``` Triggers: - Type: SCHEDULE Branches: - main.* # Run the workflow at 1:15 am (UTC+0) every Friday until the end of 2023 Expression: "15 1 ? * FRI 2022-2023" ``` `Expression` プロパティで使用できる cron 式のその他の例については、「[Expression](workflow-reference.md#workflow.triggers.expression)」を参照してください。プッシュ、プルリクエスト、スケジュールの各トリガーのその他の例については、「[例: ワークフローのトリガー](workflows-add-trigger-examples.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 手動専用トリガーの構成 CodeCatalyst コンソールの **[実行]** ボタンを使用して、チームが手動でしか開始できないようにワークフローを制限できます。この機能を構成するには、ワークフロー定義ファイルの `Triggers` セクションを削除する必要があります。`Triggers` セクションはワークフローを作成するときにデフォルトで含まれますが、このセクションは必須ではないため削除しても構いません。ワークフロー定義ファイルの `Triggers` セクションを削除して、ワークフローを手動でしか開始できないようにするには、次の手順に従います。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。ワークフローの実行の詳細については、「[ワークフローの実行](workflows-working-runs.md)」を参照してください。 ------ #### [ Visual ] **「トリガー」セクションを削除するには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図の **[ソース]** ボックスを選択します。 1. **[トリガー]** でごみ箱アイコンを選択し、ワークフローから `Triggers` セクションを削除します。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **「トリガー」セクションを削除するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. `Triggers` セクションを検索して削除します。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # ワークフロー実行の停止次の手順に従って、進行中のワークフロー実行を停止します。実行が誤って開始された場合は、実行を停止することをおすすめします。ワークフロー実行を停止すると、CodeCatalyst は進行中のアクションが完了するまで待機してから、CodeCatalyst コンソールで実行を **[停止済み]** としてマークします。開始する機会がなかったアクションは開始されず、**[中止]** としてマークされます。 **注記** 実行がキューに入れられている場合 (つまり、進行中のアクションがない場合)、実行はすぐに停止されます。ワークフロー実行の詳細については、「[ワークフローの実行](workflows-working-runs.md)」を参照してください。 **ワークフロー実行を停止するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフロー]** で **[実行]** を選択し、リストから進行中の実行を選択します。 1. **[Stop]** (停止) を選択します。 # ゲートを使用したワークフロー実行の続行防止 *ゲート*は、特定の条件が満たされない限り、ワークフロー実行が続行されないようにするために使用できるワークフローコンポーネントです。ゲートの例として、ワークフロー実行の続行を許可する前に CodeCatalyst コンソールでユーザーが承認を送信する必要がある**承認**ゲートがあります。ワークフロー内の連続するアクションの間にゲートを追加することも、最初のアクション (**ソース**のダウンロード直後に実行) の前にゲートを追加することもできます。必要に応じて、最後のアクションの後にゲートを追加することもできます。ワークフロー実行の詳細については、「[ワークフローの実行](workflows-working-runs.md)」を参照してください。 **Topics** + [ ## ゲートのタイプ ](#workflows-gates-types) + [ ## 別のアクションと並列で実行するようにゲートを設定できますか? ](#workflows-approval-parallel) + [ ## ワークフロー実行が開始されないようにするためにゲートを使用できますか? ](#workflows-gates-prevent) + [ ## ゲートの制限 ](#workflows-gate-limitations) + [ # ワークフローへのゲートの追加 ](workflows-gates-add.md) + [ # ゲートとアクションの順序付け ](workflows-gates-depends-on.md) + [ # ゲートのバージョンの指定 ](workflows-gates-version.md) ## ゲートのタイプ現在、Amazon CodeCatalyst でサポートしているゲートのタイプは**承認**ゲートのみです。詳細については、「[ワークフロー実行の承認の必須化](workflows-approval.md)」を参照してください。 ## 別のアクションと並列で実行するようにゲートを設定できますか? いいえ。ゲートはアクションの前後にしか実行できません。詳細については、「[ゲートとアクションの順序付け](workflows-gates-depends-on.md)」を参照してください。 ## ワークフロー実行が開始されないようにするためにゲートを使用できますか? はい、ただし条件があります。ワークフロー実行が*タスクを実行*できないようにすることができます。これは、ワークフロー実行が*開始*されないようにすることとは若干異なります。ワークフローがタスクを実行できないようにするには、ワークフローの一番最初のアクションの前にゲートを追加します。このシナリオでは、ワークフロー実行が*開始されます*。つまり、ソースリポジトリファイルがダウンロードされますが、ゲートのロックが解除されるまでタスクを実行できなくなります。 **注記** ワークフローが開始され、ゲートによってブロックされた場合でも、*スペースあたりの同時ワークフロー実行の最大数*クォータやその他のクォータに対してカウントされます。ワークフロークォータを超えないようにするには、ゲートを使用する代わりに、ワークフロートリガーを使用して条件付きでワークフローを開始することを検討してください。ゲートの代わりにプルリクエスト承認ルールを使用することも検討してください。クォータ、トリガー、プルリクエスト承認ルールの詳細については、「[CodeCatalyst のワークフローのクォータ](workflows-quotas.md)」、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」、「[承認ルールを使用してプルリクエストをマージするための要件を管理する](source-pull-requests-approval-rules.md)」を参照してください。 ## ゲートの制限ゲートには次の制限があります。 + コンピューティング共有機能と組み合わせてゲートを使用することはできません。この機能の詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。 + アクショングループ内でゲートを使用することはできません。アクショングループの詳細については、「[アクショングループへのアクションのグループ化](workflows-group-actions.md)」を参照してください。 # ワークフローへのゲートの追加 Amazon CodeCatalyst では、ワークフローにゲートを追加して、特定の条件が満たされていない限り、ワークフローが続行されないようにできます。ワークフローにゲートを追加するには、以下の手順に従います。ゲートの詳細については、「[ゲートを使用したワークフロー実行の続行防止](workflows-gates.md)」を参照してください。 **ゲートを追加および構成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左側で **[ゲート]** を選択します。 1. ゲートカタログでゲートを検索し、プラス記号 (**\$1**) を選択してワークフローにゲートを追加します。 1. ゲートを構成します。**[ビジュアル]** を選択してビジュアルエディタを使用するか、**[YAML]** を選択して YAML エディタを使用します。詳細な手順については、以下を参照してください。 + [「承認」ゲートの追加](workflows-approval-add.md) 1. (任意) **[検証]** を選択して、YAML コードが有効であることを確認します。 1. **[コミット]** を選択して変更をコミットします。 # ゲートとアクションの順序付け Amazon CodeCatalyst では、ワークフローアクション、アクショングループ、またはゲートの前後に実行されるゲートを設定できます。例えば、`Deploy` アクションの前に実行される `Approval` ゲートを設定できます。この場合、`Deploy` アクションは `Approval` ゲートに*依存*していることになります。ゲートとアクションの間の依存関係を設定するには、ゲートまたはアクションの **DependsOn** プロパティを構成します。手順については、「[アクション間の依存関係の設定](workflows-depends-on-set-up.md)」を参照してください。参照先の手順ではワークフロー*アクション*について言及していますが、ゲートにも等しく適用されます。ゲートを使用して **DependsOn** プロパティを設定する方法の例については、「[例: 「承認」ゲート](workflows-approval-example.md)」を参照してください。ゲートの詳細については、「[ゲートを使用したワークフロー実行の続行防止](workflows-gates.md)」を参照してください。ワークフローアクションの詳細については、「[ワークフローアクションの構成](workflows-actions.md)」を参照してください。 # ゲートのバージョンの指定デフォルトでは、ワークフローにゲートを追加すると、CodeCatalyst は次の形式を使用してワークフロー定義ファイルにフルバージョンを追加します。 `vmajor.minor.patch` 例: ``` My-Gate: Identifier: aws/approval@v1 ``` ワークフローでゲートの特定のメジャーバージョンまたはマイナーバージョンを使用するように、バージョンを延長できます。手順については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。参照先のトピックではワークフローアクションについて言及していますが、ゲートにも等しく適用されます。 CodeCatalyst におけるゲートの詳細については、「[ゲートを使用したワークフロー実行の続行防止](workflows-gates.md)」を参照してください。 # ワークフロー実行の承認の必須化ワークフロー実行を続行する前に承認を必須とするように構成できます。これを行うには、ワークフローに**承認**[ゲート](workflows-gates.md)を追加する必要があります。*承認ゲート*によって、1 人または複数のユーザーが CodeCatalyst コンソールで 1 つ以上の承認を送信するまで、ワークフローが進まなくなります。全員の承認が下りると、ゲートの「ロックが解除」されてワークフロー実行を再開できます。ワークフローで**承認**ゲートを使用して、開発チーム、オペレーションチーム、リーダーシップチームに、より広範な対象者にデプロイされる前に変更を確認する機会を提供します。ワークフロー実行の詳細については、「[ワークフローの実行](workflows-working-runs.md)」を参照してください。 **Topics** + [ ## 承認ゲートのロックを解除するにはどうすればよいですか? ](#workflows-approval-conditions) + [ ## 「承認」ゲートを使用するケース ](#workflows-approval-when) + [ ## 承認を行うことができるユーザーは誰ですか? ](#workflows-approval-who) + [ ## 承認が必須であることをユーザーに通知するにはどうすればよいですか? ](#workflows-approval-notify-methods) + [ ## ワークフロー実行が開始されないようにするために「承認」ゲートを使用できますか? ](#workflows-approval-prevent) + [ ## キュー実行モード、優先実行モード、並列実行モードにおけるワークフロー承認の仕組みはどのようになっていますか? ](#workflows-approval-run-mode) + [ # 例: 「承認」ゲート ](workflows-approval-example.md) + [ # 「承認」ゲートの追加 ](workflows-approval-add.md) + [ # 承認通知の構成 ](workflows-approval-notify.md) + [ # ワークフロー実行の承認または却下 ](workflows-approval-approve.md) + [ # 「承認」ゲート YAML ](approval-ref.md) ## 承認ゲートのロックを解除するにはどうすればよいですか? **承認**ゲートのロックを解除するには、次の条件が*すべて*満たされている必要があります。 + **条件 1**: 必要な数の承認が下りている。必要な承認数は変更可能で、各ユーザーは承認を 1 回だけ送信できます。 + **条件 2**: ゲートがタイムアウトになる前にすべての承認が下りている。ゲートはアクティブ化されてから 14 日後にタイムアウトになります。この期間は変更できません。 + **条件 3**: 誰もワークフロー実行を却下していない。一度でも却下拒否されるとワークフロー実行に失敗します。 + **条件 4**: (優先実行モードを使用している場合にのみ該当) 対象の実行が後続の実行よりも優先されない。詳細については、「[キュー実行モード、優先実行モード、並列実行モードにおけるワークフロー承認の仕組みはどのようになっていますか?](#workflows-approval-run-mode)」を参照してください。いずれかの条件が満たされない場合、CodeCatalyst はワークフローを停止し、実行ステータスを **[失敗]** (**条件 1** ～ **3** の場合) または **[優先済み]** (**条件 4** の場合) に設定します。 ## 「承認」ゲートを使用するケース通常、アプリケーションやその他のリソースを本番サーバー、または品質標準を検証する必要がある環境にデプロイするワークフローで**承認**ゲートを使用します。本番環境にデプロイする前にゲートを配置することで、レビュアーは新しいソフトウェアリビジョンが一般公開される前にそれを検証できます。 ## 承認を行うことができるユーザーは誰ですか? プロジェクトのメンバーであり、**コントリビューター**または**プロジェクト管理者**のロールを持つユーザーが承認を行うことができます。プロジェクトのスペースに属する、**スペース管理者**ロールを持つユーザーも承認を行うことができます。 **注記** **レビュアー**ロールを持つユーザーは承認を行うことができません。 ## 承認が必須であることをユーザーに通知するにはどうすればよいですか? 承認が必須であることをユーザーに通知するには、以下を行う必要があります。 + CodeCatalyst から Slack 通知を送信します。詳細については、「[承認通知の構成](workflows-approval-notify.md)」を参照してください。 + **[承認]** ボタンと **[却下]** ボタンがある CodeCatalyst コンソールのページに移動し、そのページの URL を承認者宛ての E メールまたはメッセージングアプリケーションに貼り付けます。このページへの移動方法の詳細については、「[ワークフロー実行の承認または却下](workflows-approval-approve.md)」を参照してください。 ## ワークフロー実行が開始されないようにするために「承認」ゲートを使用できますか? はい、ただし条件があります。詳細については、「[ワークフロー実行が開始されないようにするためにゲートを使用できますか?](workflows-gates.md#workflows-gates-prevent)」を参照してください。 ## キュー実行モード、優先実行モード、並列実行モードにおけるワークフロー承認の仕組みはどのようになっていますか? キュー実行モード、優先実行モード、または並列実行モードを使用する場合、**承認**ゲートは[アクション](workflows-actions.md)と同様に機能します。これらの実行モードの詳細については、「[キュー実行モードについて](workflows-configure-runs.md#workflows-configure-runs-queued)」、「[優先実行モードについて](workflows-configure-runs.md#workflows-configure-runs-superseded)」、「[並列実行モードについて](workflows-configure-runs.md#workflows-configure-runs-parallel)」の各セクションを読むことをお勧めします。各モードの基本事項を理解できたら、このセクションに戻って、**承認**ゲートが存在するときに各実行モードがどのように機能するかを確認してください。 **承認**ゲートが存在する場合、実行は次のように処理されます。 + [キュー実行モード](workflows-configure-runs.md#workflows-configure-runs-queued)を使用している場合、現在ゲートで承認を待っている実行の後ろで実行が順番待ちをすることになります。そのゲートのロックが解除されると (つまり、すべての承認が下りると)、キュー内の次の実行がゲートに進んで承認を待ちます。このプロセスは、キューに入れられた実行がゲートを通じて 1 つずつ処理されることで続行されます。[Figure 1](#figure-1-workflow-queued-run-mode-ma) はこのプロセスを示しています。 + [優先実行モード](workflows-configure-runs.md#workflows-configure-runs-superseded)を使用している場合、動作はキュー実行モードと同じです。ただし、実行がゲートのキューに蓄積されるのではなく、新しい実行が以前の実行よりも優先 (引き継ぐ) されます。キューはなく、現在ゲートで承認を待っている実行はキャンセルされ、新しい実行が優先されます。[Figure 2](#figure-2-workflow-superseded-run-mode-ma) はこのプロセスを示しています。 + [並列実行モード](workflows-configure-runs.md#workflows-configure-runs-parallel)を使用している場合、実行は並列で開始され、キューは形成されません。先行する実行がないため、各実行はすぐにゲートによって処理されます。[Figure 3](#figure-3-workflow-parallel-run-mode-ma) はこのプロセスを示しています。 **図 1**: 「キュー実行モード」と**承認**ゲート ![\[「キュー実行モード」における「承認」ゲートの動作\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/runmode-queued-ma.png) **図 2**: 「優先実行モード」と**承認**ゲート ![\[「優先実行モード」における「承認」ゲートの動作\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/runmode-superseded-ma.png) **図 3**: 「並列実行モード」と**承認**ゲート ![\[「並列実行モード」における「承認」ゲートの動作\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/runmode-parallel-ma.png) # 例: 「承認」ゲート次の例は、`Staging` と `Production` という 2 つのアクションの間に `Approval_01` という**承認**ゲートを追加する方法を示しています。`Staging` アクション、`Approval_01`ゲート、`Production` アクションの順に実行されます。`Approval_01` ゲートのロックが解除されている場合にのみ `Production` アクションが実行されます。`DependsOn` プロパティにより、`Staging`、`Approval_01`、`Production` の各フェーズが順番に実行されます。 **承認**ゲートの詳細については、「[ワークフロー実行の承認の必須化](workflows-approval.md)」を参照してください。 ``` Actions: Staging: # Deploy to a staging server Identifier: aws/ecs-deploy@v1 Configuration: ... Approval_01: Identifier: aws/approval@v1 DependsOn: - Staging Configuration: ApprovalsRequired: 2 Production: # Deploy to a production server Identifier: aws/ecs-deploy@v1 DependsOn: - Approval_01 Configuration: ... ``` # 「承認」ゲートの追加承認を必須とするようにワークフローを構成するには、ワークフローに**承認**ゲートを追加する必要があります。以下の手順に従って、ワークフローに**承認**ゲートを追加します。このゲートの詳細については、「[ワークフロー実行の承認の必須化](workflows-approval.md)」を参照してください。 ------ #### [ Visual ] **ワークフローに「承認」ゲートを追加するには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. 左上で**[ゲート]** を選択します。 1. **[ゲート]** カタログの **[承認]** でプラス記号 (**\$1**) を選択します。 1. **[入力]** を選択し、**[依存]** フィールドで以下を実行します。このゲートを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。デフォルトでは、ワークフローにゲートを追加すると、そのゲートはワークフローの最後のアクションに依存するように設定されます。このプロパティを削除すると、ゲートは何にも依存せず、他のアクションよりも先に実行されます。 **注記** ゲートは、アクション、アクショングループ、またはゲートの前後に実行されるように構成する必要があります。他のアクション、アクショングループ、ゲートと並行して実行するように設定することはできません。 **依存**機能の詳細については、「[ゲートとアクションの順序付け](workflows-gates-depends-on.md)」を参照してください。 1. **[設定]** タブを選択します。 1. **[ゲート名]** フィールドで以下を実行します。ゲートに付ける名前を指定します。すべてのゲート名は、ワークフロー内で一意である必要があります。ゲート名に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、ゲート名の特殊文字とスペースを有効にすることはできません。 1. (省略可) **[承認の数]** フィールドで以下を実行します。 **承認**ゲートのロック解除に必要な承認の最小数を指定します。最小値は `1` です。最大値は `2` です。これを省略した場合、デフォルトで `1` になります。 **注記** `ApprovalsRequired` プロパティを省略する場合は、ワークフロー定義ファイルからゲートの `Configuration` セクションを削除します。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **ワークフローに「承認」ゲートを追加するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 次の例を参考にして、`Approval` セクションとベースとなるプロパティを追加します。詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」の「[「承認」ゲート YAML](approval-ref.md)」を参照してください。 ``` Actions: MyApproval_01: Identifier: aws/approval@v1 DependsOn: - PreviousAction Configuration: ApprovalsRequired: 2 ``` 別の例については、「[例: 「承認」ゲート](workflows-approval-example.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 承認通知の構成ワークフロー実行に承認が必要であることをユーザーに知らせる通知を CodeCatalyst から Slack チャンネルに送信できます。ユーザーは通知を表示し、通知内のリンクをクリックします。リンクをクリックすると CodeCatalyst の承認ページが表示され、そこでワークフローを承認または却下できます。ワークフローが承認/却下されたこと、または承認リクエストの有効期限が切れたことをユーザーに通知するように構成することもできます。 Slack 通知を設定するには、以下の手順に従います。 **開始する前に** ワークフローに**承認**ゲートを追加していることを確認してください。詳細については、「[「承認」ゲートの追加](workflows-approval-add.md)」を参照してください。 **Slack チャンネルにワークフロー承認通知を送信するには** 1. Slack で CodeCatalyst を構成します。詳細については、「[Slack 通知の使用開始](getting-started-notifications.md)」を参照してください。 1. 承認が必要なワークフローを含む CodeCatalyst プロジェクトで、まだ有効になっていない場合は通知を有効にします。通知を有効化するには: 1. プロジェクトに移動し、ナビゲーションペインで **[プロジェクト設定]** を選択します。 1. 上部で **[通知]** を選択します。 1. **[通知イベント]** で **[通知を編集]** を選択します。 1. **[保留中のワークフロー承認]** をオンにし、CodeCatalyst から通知を送信する Slack チャンネルを選択します。 1. (省略可) 承認、却下、期限切れの承認についてユーザーに知らせるには他の通知をオンにします。**[ワークフロー実行の承認]**、**[ワークフロー実行の却下]**、**[ワークフロー承認の優先]**、**[ワークフロー承認のタイムアウト]** をオンにできます。各通知の横にある、CodeCatalyst から通知を送信する Slack チャンネルを選択します。 1. **[保存]** を選択します。 # ワークフロー実行の承認または却下 **承認**ゲートを含むワークフロー実行は承認または却下する必要があります。ユーザーは以下から承認または却下を行うことができます。 + CodeCatalyst コンソール + チームメンバーから提供されたリンク + Slack の自動通知ユーザーが承認または却下した後、この決定を取り消すことはできません。 **注記** ワークフロー実行を承認または却下できるのは一部のユーザーのみです。詳細については、「[承認を行うことができるユーザーは誰ですか?](workflows-approval.md#workflows-approval-who)」を参照してください。 **[開始する前に]** ワークフローに**承認**ゲートを追加していることを確認してください。詳細については、「[「承認」ゲートの追加](workflows-approval-add.md)」を参照してください。 **CodeCatalyst コンソールからワークフロー実行を承認または却下するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. ワークフロー図で、**承認**ゲートを表すボックスを選択します。サイドパネルが表示されます。 **注記** この時点で、必要に応じてこのページの URL を他の承認者に送信できます。 1. **[決定内容の確認]** で **[承認]** または **[却下]** を選択します。 1. (省略可) **[コメント - 省略可]** で、ワークフロー実行を承認または却下した理由がわかるコメントを入力します。 1. [**Submit**] を選択してください。 **チームメンバーから提供されたリンクからワークフロー実行を承認または却下するには** 1. チームメンバーから送信されたリンクを選択します (チームメンバーにさきほど記の手順を読んでもらってリンクを取得できます)。 1. 求められた場合は CodeCatalyst にサインインします。ワークフロー実行の承認ページにリダイレクトされます。 1. **[決定内容の確認]** で **[承認]** または **[却下]** を選択します。 1. (省略可) **[コメント - 省略可]** で、ワークフロー実行を承認または却下した理由がわかるコメントを入力します。 1. [**Submit**] を選択してください。 **Slack の自動通知からワークフロー実行を承認または却下するには** 1. Slack 通知が設定されていることを確認します。「[承認通知の構成](workflows-approval-notify.md)」を参照してください。 1. Slack の承認通知が送信されたチャンネルで、承認通知のリンクを選択します。 1. 求められた場合は CodeCatalyst にサインインします。ワークフロー実行ページにリダイレクトされます。 1. ワークフロー図で承認ゲートを選択します。 1. **[決定内容の確認]** で **[承認]** または **[却下]** を選択します。 1. (省略可) **[コメント - 省略可]** で、ワークフロー実行を承認または却下した理由がわかるコメントを入力します。 1. [**Submit**] を選択します。 # 「承認」ゲート YAML 以下は、**[承認]** ゲートの YAML 定義です。このゲートを使用する方法については、「[ワークフロー実行の承認の必須化](workflows-approval.md)」を参照してください。このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The 'Approval' gate definition starts here. Approval: Identifier: aws/approval@v1 DependsOn: - another-action Configuration: ApprovalsRequired: number ``` ## Approval (必須) ゲートに付ける名前を指定します。すべてのゲート名は、ワークフロー内で一意である必要があります。ゲート名に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、ゲート名の特殊文字とスペースを有効にすることはできません。デフォルト: `Approval_nn`。対応する UI: [設定] タブ/**[ゲート名]** ## Identifier (*Approval*/**Identifier**) (必須) ゲートを識別します。**[承認]** ゲートはバージョン `1.0.0` をサポートしています。バージョンを短縮しない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。デフォルト: `aws/approval@v1`。対応する UI: ワークフロー図/Approval\$1nn/**aws/approval@v1** ラベル ## DependsOn (*Approval*/**DependsOn**) (オプション) このゲートを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。デフォルトでは、ワークフローにゲートを追加すると、そのゲートはワークフローの最後のアクションに依存するように設定されます。このプロパティを削除すると、ゲートは何にも依存せず、他のアクションよりも先に実行されます。 **注記** ゲートは、アクション、アクショングループ、またはゲートの前後に実行されるように構成する必要があります。他のアクション、アクショングループ、ゲートと並行して実行するように設定することはできません。 **依存**機能の詳細については、「[ゲートとアクションの順序付け](workflows-gates-depends-on.md)」を参照してください。対応する UI: [入力] タブ/**[依存]** ## Configuration (*Approval*/**Configuration**) (オプション) ゲートの設定プロパティを定義できるセクション。対応する UI: **[設定]** タブ ## ApprovalsRequired (*Approval*/Configuration/**ApprovalsRequired**) (オプション) 承認ゲートのロック解除に必要な **[承認]** の最小数を指定します。最小値は `1` です。最大値は `2` です。これを省略した場合、デフォルトで `1` になります。 **注記** `ApprovalsRequired` プロパティを省略する場合は、ワークフロー定義ファイルからゲートの [`Configuration`] セクションを削除します。対応する UI: [設定] タブ/**[承認数]** # 実行のキュー動作の構成 Amazon CodeCatalyst のデフォルトでは、複数のワークフロー実行が同時に発生すると、CodeCatalyst がそれらをキューに入れ、開始された順序で 1 つずつ処理します。このデフォルトの動作は、*実行モード*を指定することで変更できます。以下の実行モードがあります。 + (デフォルト) キュー実行モード – CodeCatalyst は実行を 1 つずつ処理します。 + 優先実行モード – CodeCatalyst は実行を 1 つずつ処理し、新しい実行が古い実行を追い越します。 + 並列実行モード – CodeCatalyst は複数の実行を並列で処理します。ワークフロー実行の詳細については、「[ワークフローの実行](workflows-working-runs.md)」を参照してください。 **Topics** + [ ## キュー実行モードについて ](#workflows-configure-runs-queued) + [ ## 優先実行モードについて ](#workflows-configure-runs-superseded) + [ ## 並列実行モードについて ](#workflows-configure-runs-parallel) + [ ## 実行モードの構成 ](#workflows-configure-runs-configure) ## キュー実行モードについて *キュー実行モード*では、実行は順番に行われ、待機中の実行がキューを形成します。アクションとアクショングループへのエントリポイントでキューが形成されるため、*同じワークフロー内に複数のキュー*を含めることができます (「[Figure 1](#figure-1-workflow-queued-run-mode)」を参照)。キューに入れられた実行がアクションに入ると、アクションはロックされ、他の実行は入れなくなります。実行が終了してアクションを終了すると、アクションのロックが解除され、次の実行の準備が整います。 [Figure 1](#figure-1-workflow-queued-run-mode) は、キュー実行モードで構成されたワークフローを示しています。以下が示されています。 + ワークフローを通過する 7 つの実行 + 2 つのキュー: 1 つは入力ソース (**Repo:main**) に入る前のキュー、もう 1 つは **BuildTestActionGroup** アクションに入る前のキュー + 2 つのロックされたブロック: 入力ソース (**Repo:main**) と **BuildTestActionGroup** ワークフロー実行の処理が終了する時の動作は次のようになります。 + **Run-4d444** がソースリポジトリのクローン作成を終了すると、入力ソースを出てキューで **Run-3c333** の後ろに入ります。次に、**Run-5e555** が入力ソースに入ります。 + **Run-1a111** が構築とテストを終了すると、**BuildTestActionGroup** アクションを出て **DeployAction** アクションに入ります。次に、**Run-2b222** が **BuildTestActionGroup** アクションに入ります。 **図 1**: 「キュー実行モード」で構成されたワークフロー ![\[「キュー実行モード」で構成されたワークフロー\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png) 次の場合はキュー実行モードを使用します。 + **機能と実行の間で 1 対 1 の関係を維持したい (これらの機能は優先モードを使用する場合にグループ化されることがある)**: 例えば、コミット 1 で機能 1 をマージすると実行 1 が開始され、コミット 2 で機能 2 をマージすると実行 2 が開始され、その後も同様に続いていきます。キューモードの代わりに優先モードを使用する場合、機能 (およびコミット) は他よりも優先される実行でグループにまとめられます。 + **並列モードを使用する際に発生する可能性のあるレース条件や予期しない問題を回避したいと考えている**: 例えば、Wang と Saanvi の 2 人のソフトウェアデベロッパーが、ワークフローをほぼ同時に開始して Amazon ECS クラスターにデプロイする場合、Wang の実行はクラスターで統合テストを開始し、Saanvi の実行は新しいアプリケーションコードをクラスターにデプロイするため、Wang のテストが失敗するか、間違ったコードをテストする可能性があります。別の例として、ロックメカニズムを持たないターゲットがある場合、2 つの実行が予期しない方法で互いの変更を上書きする可能性があります。 + CodeCatalyst が実行の処理に使用するコンピューティングリソースの**負荷を制限したい**: 例えば、ワークフローに 3 つのアクションがある場合、同時に最大 3 つの実行を走らせることができます。一度に走らせることができる実行数の上限を設定すると、実行スループットを予測しやすくなります。 + ワークフローによって**サードパーティーのサービスに対して行われたリクエストの数を制限したい**: 例えば、Docker Hub からイメージをプルする手順を含むビルドアクションがワークフローにある場合があります。アカウントごとに 1 時間で実行できる[プルリクエストの数は Docker Hubによって制限されており](https://www.docker.com/increase-rate-limits)、制限を超えるとロックアウトされます。キュー実行モードを使用して実行スループットを遅くすると、Docker Hub へのリクエストが 1 時間あたりに生成される回数が少なくなり、ロックアウトやビルドおよび実行の失敗が発生する可能性が低くなります。 **最大キューサイズ**: 50 **[最大キューサイズ]** に関する注意事項: + 最大キューサイズとは、ワークフロー内の*すべてのキュー*を合算して許可されている実行の最大数を指します。 + キュー内の実行数が 50 件を超えると、CodeCatalyst では 51 件目以降の実行が削除されます。 **失敗動作**: アクションによって処理されている間に実行が応答しなくなった場合、その実行の後の実行は、アクションがタイムアウトするまでキューに保持されます。アクションは 1 時間後にタイムアウトします。アクション内で実行が失敗した場合、その後にあるキューの先頭の実行の続行が許可されます。 ## 優先実行モードについて *優先実行モード*は*キュー実行モード*と同じですが、以下のような違いがあります。 + キューに入れられている実行がキュー内の別の実行に追いついた場合、後続の実行が前の実行よりも優先 (引き継ぎ) され、前の実行がキャンセルされて「優先済み」としてマークされます。 + 最初の箇条書きで説明されている動作の結果として、優先実行モードが使用されている場合にキューに含められる実行は 1 つだけとなります。 [Figure 1](#figure-1-workflow-queued-run-mode) のワークフローを参考として使用し、このワークフローに優先実行モードを適用すると、次のような結果になります。 + **Run-7g777** はキュー内の他の 2 つの実行より優先され、これが **Queue \$11** に残る唯一の実行になります。**Run-6f666** と **Run-5e555** はキャンセルされます。 + **Run-3c333** は **Run-2b222** より優先され、**Queue \$12** に残る唯一の実行になります。**Run-2b222** はキャンセルされます。以下が必要な場合に優先実行モードを使用します。 + キューモードよりも高いスループット + キューモードよりもサードパーティーサービスへのリクエストの数を少なくする (Docker Hub などのサードパーティーサービスにレート制限がある場合に便利) ## 並列実行モードについて *並列実行モード*では、実行は互いに独立しており、他の実行が完了するまで待たずに開始します。キューはなく、ワークフロー内のアクションが完了するまでにかかる速度にのみ実行スループットが制限されます。ユーザーごとに独自の機能ブランチがあり、他のユーザーと共有していないターゲットにデプロイする開発環境で並列実行モードを使用します。 **重要** 本番環境の Lambda 関数など、複数のユーザーがデプロイできる共有ターゲットがある場合は、競合状態が発生する可能性があるため、並列モードを使用しないでください。並列ワークフロー実行が共有リソースを同時に変更しようとしたときに*競合状態*が発生し、予測不可能な結果につながります。 **並列実行の最大数**: CodeCatalyst スペースあたり 1,000 ## 実行モードの構成実行モードは、キュー実行モード、優先実行モード、または並列実行モードに設定できます。デフォルトはキュー実行モードです。実行モードをキュー実行モードまたは優先実行モードから並列実行モードに変更すると、CodeCatalyst ではキューに入っている実行をキャンセルし、アクションによって現在処理されている実行をキャンセルする前に完了することが許可されます。実行モードを並列実行モードからキュー実行モードまたは優先実行モードに変更すると、CodeCatalyst では現在実行中のすべての並列実行を完了できます。実行モードをキュー実行モードまたは優先実行モード変更した後に開始した実行では、新しいモードが使用されます。 ------ #### [ Visual ] **ビジュアルエディタを使用して実行モードを変更するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. 右上の **[ワークフローのプロパティ]** を選択します。 1. **[詳細]** を展開し、**[実行モード]** で次のいずれかを選択します。 1. **キュー** - 「[キュー実行モードについて](#workflows-configure-runs-queued)」を参照 1. **優先** - 「[優先実行モードについて](#workflows-configure-runs-superseded)」を参照 1. **並列** – 「[並列実行モードについて](#workflows-configure-runs-parallel)」を参照 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して実行モードを変更するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. `RunMode` プロパティを次のように追加します。 ``` Name: Workflow_6d39 SchemaVersion: "1.0" RunMode: QUEUED|SUPERSEDED|PARALLEL ``` 詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」の「[最上位プロパティ](workflow-reference.md#workflow.top.level)」セクションの `RunMode` プロパティの説明を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # ワークフロー実行間のファイルのキャッシュファイルキャッシュを有効にすると、ビルドアクションとテストアクションでディスク上のファイルがキャッシュに保存され、後続のワークフロー実行でそのキャッシュから復元されます。実行間で変更されていない依存関係を構築またはダウンロードすることで生じるレイテンシーがキャッシュによって軽減されます。CodeCatalyst ではフォールバックキャッシュもサポートしており、必要な依存関係の一部を含む部分的なキャッシュを復元するために使用できます。これにより、キャッシュミスによるレイテンシーの影響を軽減できます。 **注記** ファイルキャッシュは Amazon CodeCatalyst の[ビルド](build-workflow-actions.md)アクションと[テスト](test-workflow-actions.md)アクションでのみ利用可能で、**EC2** [コンピューティングタイプ](workflows-working-compute.md#compute.types)を使用するように構成されている場合しか利用できません。 **Topics** + [ ## ファイルキャッシュについて ](#workflows-caching.files) + [ ## キャッシュの作成 ](#workflows-caching.fallback) + [ ## ファイルキャッシュの制約 ](#workflows-caching.constraints) ## ファイルキャッシュについてファイルキャッシュを使用すると、データを複数のキャッシュに整理できます。各キャッシュは `FileCaching` プロパティで参照されます。各キャッシュは、特定のパスで指定されたディレクトリを保存します。指定されたディレクトリは今後のワークフロー実行で復元されます。以下は、`cacheKey1` と `cacheKey2` という名前の複数のキャッシュでキャッシュするための YAML スニペットの例です。 ``` Actions: BuildMyNpmApp: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: npm install - Run: npm run test Caching: FileCaching: cacheKey1: Path: file1.txt RestoreKeys: - restoreKey1 cacheKey2: Path: /root/repository RestoreKeys: - restoreKey2 - restoreKey3 ``` **注記** CodeCatalyst では、ローカルキャッシュとリモートキャッシュで構成される多層キャッシュを使用します。プロビジョニングされたフリートまたはオンデマンドマシンがローカルキャッシュでキャッシュミスに遭遇すると、依存関係がリモートキャッシュから復元されます。その結果、一部のアクション実行では、リモートキャッシュのダウンロードからレイテンシーが発生する可能性があります。 CodeCatalyst ではキャッシュアクセス制限を適用して、あるワークフロー内のアクションが別のワークフローからキャッシュを変更できないようにします。これにより、ビルドやデプロイに影響を与える誤ったデータがプッシュされる可能性のある他のワークフローから各ワークフローを保護します。キャッシュをすべてのワークフローとブランチのペアリングに分離するキャッシュスコープを使用して制限が適用されます。例えば、ブランチ `feature-A` の `workflow-A` には、兄弟ブランチ `feature-B` の `workflow-A` とは異なるファイルキャッシュがあります。ワークフローが指定されたファイルキャッシュを検索し、それを見つけられないときにキャッシュミスが発生します。新しいブランチを作成する際や、新しいキャッシュが参照されてそれがまだ作成されていない場合など、複数の理由でキャッシュミスが発生する可能性があります。また、キャッシュの有効期限が切れたときに発生する場合もあります。デフォルトでは、キャッシュが最後に使用された日から 14 日後に有効期限が切れます。キャッシュミスを軽減し、キャッシュヒット率を高めるために、CodeCatalyst ではフォールバックキャッシュをサポートしています。フォールバックキャッシュは代替キャッシュであり、キャッシュの古いバージョンである部分キャッシュを復元する機会を提供します。キャッシュは、最初にプロパティ名の `FileCaching` で一致を検索して復元され、見つからない場合は `RestoreKeys` を評価します。プロパティ名とすべての `RestoreKeys` の両方にキャッシュミスがある場合、キャッシュはベストエフォートであり、保証されないため、ワークフローは引き続き実行されます。 ## キャッシュの作成次の手順に従って、ワークフローにキャッシュを追加できます。 ------ #### [ Visual ] **ビジュアルエディタを使用してキャッシュを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、キャッシュを追加するアクションを選択します。 1. **[設定]** を選択します。 1. **[ファイルのキャッシュ - 省略可]** で、**[キャッシュを追加]** を選択して次のようにフィールドに情報を入力します。 **キー** プライマリキャッシュプロパティ名の名前を指定します。キャッシュプロパティ名は、ワークフロー内で一意である必要があります。各アクションには、`FileCaching` に最大 5 つのエントリを含めることができます。 **[Path]** (パス) キャッシュの関連するパスを指定します。 **復元キー - 省略可** プライマリキャッシュプロパティが見つからない場合にフォールバックとして使用する復元キーを指定します。復元キー名は、ワークフロー内で一意である必要があります。各キャッシュには、`RestoreKeys` に最大 5 つのエントリを含めることができます。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用してキャッシュを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ワークフローアクションで、次のようなコードを追加します。 ``` action-name: Configuration: Steps: ... Caching: FileCaching: key-name: Path: file-path # # Specify any additional fallback caches # RestoreKeys: # - restore-key ``` 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ ## ファイルキャッシュの制約プロパティ名と `RestoreKeys` の制約は次のとおりです。 + 名前はワークフロー内で一意である必要があります。 + 名前に使用できるのは、英数字 (A～Z、a～z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。 + 名前は 180 文字まで入力できます。 + 各アクションには、`FileCaching` に最大 5 つのキャッシュを含めることができます。 + 各キャッシュには、`RestoreKeys` に最大 5 つのエントリを含めることができます。パスの制約は以下のとおりです。 + アスタリスク (\$1) は使用できません。 + パスは 255 文字まで入力できます。 # ワークフロー実行のステータスと詳細の表示 Amazon CodeCatalyst では、1 つのワークフロー実行のステータスと詳細、または複数の実行を同時に表示できます。実行状態の一覧については、「[ワークフロー実行の状態](workflows-view-run-status.md)」を参照してください。 **注記** ワークフロー*実行*ステータスとは異なるワークフローステータスを表示することもできます。詳細については、「[ワークフローのステータスの表示](workflows-view-status.md)」を参照してください。ワークフロー実行の詳細については、「[ワークフローの実行](workflows-working-runs.md)」を参照してください。 **Topics** + [ ## 1 つの実行のステータスと詳細の表示 ](#workflows-view-run-single) + [ ## プロジェクト内のすべての実行のステータスと詳細の表示 ](#workflows-view-run-all) + [ ## 特定のワークフローのすべての実行のステータスと詳細の表示 ](#workflows-view-run-wf) + [ ## ワークフロー図でのワークフローの実行の表示 ](#workflows-view-run-wf-diagram) ## 1 つの実行のステータスと詳細の表示 1 つのワークフロー実行のステータスと詳細を表示して、成功したかどうか、完了時刻、開始者を確認できます。 **1 つの実行のステータスと詳細を表示するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. ワークフローの名前の下で **[実行]** を選択します。 1. **[実行履歴]** の **[実行 ID]** 列で実行を選択します。例えば、`Run-95a4d`。 1. 実行の名前の下で、次のいずれかを実行します。 + ワークフロー実行のアクションとそのステータスを示すワークフロー図を表示するには **[ビジュアル]** を選択します (「[ワークフロー実行の状態](workflows-view-run-status.md)」を参照)。このビューには、実行中に使用されるソースリポジトリとブランチも表示されます。ワークフロー図でアクションを選択すると、実行中にアクションによって生成されたログ、レポート、出力などの詳細が表示されます。表示される情報は、どのアクションタイプが選択されているかによって異なります。ビルドログまたはデプロイログの表示の詳細については、「[ビルドアクションの結果の表示](build-view-results.md)」または「[デプロイログの表示](deploy-deployment-logs.md)」を参照してください。 + 実行に使用されたワークフロー定義ファイルを表示するには **[YAML]** を選択します。 + ワークフロー実行によって生成されたアーティファクトを表示するには **[アーティファクト]** を選択します。アーティファクトの詳細については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 + ワークフロー実行によって生成されたテストレポートやその他のタイプのレポートを表示するには **[レポート]** を選択します。レポートの詳細については、「[品質レポートのタイプ](test-workflow-actions.md#test-reporting)」を参照してください。 + ワークフロー実行によって生成された出力変数を表示するには **[変数]** を選択します。変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 **注記** 実行の親ワークフローが削除された場合、この事実を示すメッセージが実行詳細ページの上部に表示されます。 ## プロジェクト内のすべての実行のステータスと詳細の表示プロジェクト内のすべてのワークフロー実行のステータスと詳細を表示して、プロジェクトで行われているワークフローアクティビティの量を理解し、ワークフローの全体的な健全性を把握できます。 **プロジェクト内のすべての実行のステータスと詳細を表示するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフロー]** で **[実行]** を選択します。すべてのワークフロー、すべてのブランチ、プロジェクト内のすべてのリポジトリのすべての実行が表示されます。ページには以下の列があります。 + **実行 ID** — 実行の一意の識別子。実行 ID リンクを選択すると、実行に関する詳細情報が表示されます。 + **ステータス** – ワークフロー実行の処理ステータス。実行状態の詳細については、「[ワークフロー実行の状態](workflows-view-run-status.md)」を参照してください。 + **トリガー** – ワークフロー実行を開始したユーザー、コミット、プルリクエスト (PR)、またはスケジュール。詳細については、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + **ワークフロー** – 実行が開始されたワークフローの名前、およびワークフロー定義ファイルが存在するソースリポジトリとブランチ。この情報を表示するには、列の幅を拡げる必要がある場合があります。 **注記** この列が **[使用不可]** に設定されている場合、通常は関連ワークフローが削除または移動されたことが原因です。 + **開始時刻** – ワークフロー実行が開始された時刻。 + **所要時間** – ワークフロー実行が処理されるまでにかかった時間。所用時間が非常に長いか非常に短い場合は、問題が発生している可能性があります。 + **終了時刻** – ワークフロー実行が終了した時刻。 ## 特定のワークフローのすべての実行のステータスと詳細の表示特定のワークフローに関連付けられているすべての実行のステータスと詳細を表示して、ワークフロー内にボトルネックが発生させている実行がないか確認したり、現在進行中または完了した実行を確認したりできます。 **特定のワークフローのすべての実行のステータスと詳細を表示するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. ワークフローの名前の下で **[実行]** を選択します。選択したワークフローに関連付けられている実行が表示されます。このページは次の 2 つのセクションに分かれています。 + **アクティブな実行** - 進行中の実行が表示されます。これらの実行は次のいずれかの状態になります: **進行中**。 + **実行履歴** – 完了した (つまり、進行中ではない) 実行が表示されます。実行状態の詳細については、「[ワークフロー実行の状態](workflows-view-run-status.md)」を参照してください。 ## ワークフロー図でのワークフローの実行の表示ワークフローを進んでいく、ワークフローのすべての実行のステータスをまとめて表示できます。(リストビューとは反対に) 実行はワークフロー図内に表示されます。そのため、どの実行がどのアクションによって処理され、どの実行がキューで待機しているかを視覚的に把握できます。 **ワークフローを進んでいく複数の実行のステータスをまとめて表示するには** **注記** キュー実行モードまたは優先実行モードをワークフローで使用している場合にのみこの手順が該当します。詳細については、「[実行のキュー動作の構成](workflows-configure-runs.md)」を参照してください。 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 **注記** 実行ページではなく、ワークフローページを確認してください。 1. 左上の **[最新の状態]** タブを選択します。ワークフロー図が表示されます。 1. ワークフロー図を確認します。この図には、ワークフロー内で現在進行中のすべての実行と、完了した最新の実行が表示されます。より具体的には、以下のような例が挙げられます。 + **[ソース]** の前に上部に表示される実行はキューに入れられており、開始を待機しています。 + アクション間に表示される実行はキューに入れられており、次のアクションによって処理されるのを待機しています。 + アクション内に表示される実行は、1. 現在アクションによって処理されている、2. アクションによる処理が完了している、または 3. アクションによって処理されなかった (通常は前のアクションが失敗したことが原因) のいずれかです。 # ワークフローアクションの構成 *アクション*はワークフローの主要な構成要素であり、ワークフローの実行中に実行する作業またはタスクの論理単位を定義します。通常、ワークフローには、設定方法に応じて順次または並列に実行される複数のアクションが含まれます。 **Topics** + [ ## アクションタイプ ](#workflows-actions-types) + [ # ワークフローへのアクションの追加 ](workflows-add-action.md) + [ # ワークフローからのアクションの削除 ](workflows-delete-action.md) + [ # カスタムアクションの開発 ](workflows-custom-action.md) + [ # アクショングループへのアクションのグループ化 ](workflows-group-actions.md) + [ # アクションの順序付け ](workflows-depends-on.md) + [ # アクション間でのアーティファクトとファイルの共有 ](workflows-working-artifacts.md) + [ # 使用するアクションバージョンの指定 ](workflows-action-versions.md) + [ # 使用可能なアクションバージョンの一覧表示 ](workflows-action-versions-determine.md) + [ # アクションのソースコードの表示 ](workflows-view-source.md) + [ # GitHub Actions との統合 ](integrations-github-actions.md) ## アクションタイプ Amazon CodeCatalyst ワークフロー内では、次のタイプのアクションを使用できます。 **Topics** + [ ### CodeCatalyst アクション ](#workflows-actions-types-cc) + [ ### CodeCatalyst Labs アクション ](#workflows-actions-types-cc-labs) + [ ### GitHub Actions ](#workflows-actions-types-github) + [ ### サードパーティーアクション ](#workflows-actions-types-3p) ### CodeCatalyst アクション *CodeCatalyst アクション*は、CodeCatalyst 開発チームによって作成、維持管理、完全にサポートされるアクションです。アプリケーションを構築、テスト、デプロイするための CodeCatalyst アクションに加え、 AWS Lambda 関数の呼び出しなどのさまざまなタスクを実行する CodeCatalyst アクションもあります。次の CodeCatalyst アクションを使用できます。 + **Build** このアクションはアーティファクトを構築し、Docker コンテナでユニットテストを実行します。詳細については、「[ビルドアクションの追加](build-add-action.md)」を参照してください。 + **Test** このアクションは、アプリケーションまたはアーティファクトに対して統合テストとシステムテストを実行します。詳細については、「[テストアクションの追加](test-add-action.md)」を参照してください。 + **Amazon S3 公開** このアクションは、アプリケーションアーティファクトを Amazon S3 バケットにコピーします。詳細については、「[ワークフローを使用して Amazon S3 にファイルを発行する](s3-pub-action.md)」を参照してください。 + **AWS CDK bootstrap** このアクションは、が CDK アプリケーションをデプロイ AWS CDK するために必要なリソースをプロビジョニングします。詳細については、「[ワークフローを使用して AWS CDK アプリをブートストラップする](cdk-boot-action.md)」を参照してください。 + **AWS CDK デプロイ** このアクションはアプリケーションを合成してデプロイします AWS Cloud Development Kit (AWS CDK) 。詳細については、「[ワークフローを使用した AWS CDK アプリケーションのデプロイ](cdk-dep-action.md)」を参照してください。 + **AWS Lambda 呼び出し** このアクションは AWS Lambda 関数を呼び出します。詳細については、「[ワークフローを使用して Lambda 関数を呼び出す](lam-invoke-action.md)」を参照してください。 + **GitHub Actions** このアクションは、CodeCatalyst ワークフロー内で GitHub Actions を実行できるようにする *CodeCatalyst* アクションです。詳細については、「[ワークフローを使用して Lambda 関数を呼び出す](lam-invoke-action.md)」を参照してください。 + **スタックをデプロイ CloudFormation する** このアクションは CloudFormation スタックをデプロイします。詳細については、「[CloudFormation スタックのデプロイ](deploy-action-cfn.md)」を参照してください。 + **Amazon ECS へのデプロイ** このアクションは、Amazon ECS タスク定義を登録し、Amazon ECS サービスにデプロイします。詳細については、「[ワークフローを使用した Amazon ECS へのデプロイ](deploy-action-ecs.md)」を参照してください。 + **Kubernetes クラスターへのデプロイ** このアクションは、アプリケーションを Kubernetes クラスターにデプロイします。詳細については、「[ワークフローを使用して Amazon EKS にデプロイする](deploy-action-eks.md)」を参照してください。 + **Amazon ECS タスク定義のレンダリング** このアクションは、コンテナイメージ URI を Amazon ECS タスク定義 JSON ファイルに挿入し、新しいタスク定義ファイルを作成します。詳細については、「[Amazon ECS タスク定義の変更](render-ecs-action.md)」を参照してください。 CodeCatalyst アクションのドキュメントは、このガイドおよび各アクションの readme で入手できます。使用可能な CodeCatalyst アクションと、それをワークフローに追加する方法については、「[ワークフローへのアクションの追加](workflows-add-action.md)」を参照してください。 ### CodeCatalyst Labs アクション *CodeCatalyst Labs アクション*は、実験アプリケーションの実証基盤である Amazon CodeCatalyst Labs の一部であるアクションです。CodeCatalyst Labs アクションは、 AWS サービスとの統合を紹介するために開発されました。次の CodeCatalyst Labs アクションを使用できます。 + ** AWS Amplify ホスティングにデプロイする** このアクションは、アプリケーションを Amplify Hosting にデプロイします。 + **にデプロイする AWS App Runner** このアクションは、ソースイメージリポジトリ内の最新イメージを App Runner にデプロイします。 + **Amazon CloudFront と Amazon S3 へのデプロイ** このアクションは、アプリケーションを CloudFront と Amazon S3 にデプロイします。 + **を使用してデプロイする AWS SAM** このアクションは、 AWS Serverless Application Model (AWS SAM) を使用してサーバーレスアプリケーションをデプロイします。 + **Amazon CloudFront キャッシュの無効化** このアクションは、特定のパスセットの CloudFront キャッシュを無効にします。 + **送信 Webhook** このアクションにより、ユーザーは HTTPS リクエストを使用してワークフロー内のメッセージを任意のウェブサーバーに送信できます。 + **への発行 AWS CodeArtifact** このアクションは CodeArtifact リポジトリにパッケージを公開します。 + **Amazon SNS への公開** このアクションにより、ユーザーはトピックの作成、トピックへの公開、またはトピックへのサブスクライブによって Amazon SNS と統合できます。 + **Amazon ECR へのプッシュ** このアクションは、Docker イメージを構築して Amazon Elastic Container Registry (Amazon ECR) リポジトリに公開します。 + **Amazon CodeGuru Security を使用したスキャン** このアクションは、構成されたコードパスの zip アーカイブを作成し、CodeGuru Security を使用してコードスキャンを実行します。 + **Terraform Community Edition** このアクションは Terraform Community Edition の `plan` オペレーションと `apply` オペレーションを実行します。 CodeCatalyst Labs アクションのドキュメントは、各アクションの readme で入手できます。 CodeCatalyst Labs アクションをワークフローに追加し、その readme を表示する方法については、「[ワークフローへのアクションの追加](workflows-add-action.md)」を参照してください。 ### GitHub Actions *GitHub アクション*は [CodeCatalyst アクション](#workflows-actions-types-cc) とよく似ていますが、GitHub ワークフローで使用するために開発された点が異なります。GitHub Actions の詳細については、[GitHub Actions](https://docs.github.com/en/actions) ドキュメントを参照してください。 GitHub Actions は、CodeCatalyst ワークフローのネイティブ CodeCatalyst アクションとともに使用できます。利便性のために、CodeCatalyst コンソールでは、いくつかの人気の GitHub Actions にアクセスできるようになっています。[GitHub Marketplace](https://github.com/marketplace/actions) に掲載されている GitHub アクションを使用することもできます (いくつかの制限があります)。 GitHub Actions のドキュメントは、各アクションの readme で入手できます。詳細については、「[GitHub Actions との統合](integrations-github-actions.md)」を参照してください。 ### サードパーティーアクション *サードパーティーアクション*は、サードパーティーベンダーによって作成され、CodeCatalyst コンソールで利用できるアクションです。サードパーティーアクションの例には、Mend によって作成された **Mend SCA** アクションや、Sonar によって作成された **SonarCloud Scan** アクションなどがあります。サードパーティーアクションのドキュメントは、各アクションの readme で入手できます。サードパーティーベンダーから追加のドキュメントが提供されている場合もあります。ワークフローへのサードパーティーアクションの追加と readme の表示については、「[ワークフローへのアクションの追加](workflows-add-action.md)」を参照してください。 # ワークフローへのアクションの追加次の手順に従って、ワークフローにアクションを追加して構成します。 **アクションを追加および構成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. 左上で **[\$1 アクション]** を選択すると、**[アクション]** カタログが表示されます。 1. ドロップダウンリストで、次のいずれかを実行します。 + **[Amazon CodeCatalyst]** を選択すると、[CodeCatalyst](workflows-actions.md#workflows-actions-types-cc)、[CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs)、または[サードパーティー](workflows-actions.md#workflows-actions-types-3p)のアクションが表示されます。 + CodeCatalyst アクションには **[ AWSによるアクション]** ラベルがあります。 + CodeCatalyst Labs アクションには **[CodeCatalyst Labs のよるアクション]** ラベルがあります。 + サードパーティーアクションには **[*ベンダー*によるアクション]** ラベルがあり、*ベンダー*はサードパーティーベンダーの名前です。 + **[GitHub]** を選択すると、[GitHub Actions の厳選されたリスト](integrations-github-action-add-curated.md)が表示されます。 1. アクションカタログでアクションを検索し、次のいずれかを実行します。 + プラス記号 (**\$1**) を選択して、ワークフローにアクションを追加します。 + アクションの名前を選択して、その readme を表示します。 1. アクションを構成します。**[ビジュアル]** を選択してビジュアルエディタを使用するか、**[YAML]** を選択して YAML エディタを使用します。詳細な手順については、以下のリンクを参照してください。 [CodeCatalyst アクション](workflows-actions.md#workflows-actions-types-cc)を追加する手順については、以下を参照してください。 + [ビルドアクションの追加](build-add-action.md) + [テストアクションの追加](test-add-action.md) + [「Amazon ECS にデプロイ」アクションの追加](deploy-action-ecs-adding.md) + [「Kubernetes クラスターにデプロイ」アクションの追加](deploy-action-eks-adding.md) + [CloudFormation 「スタックのデプロイ」アクションの追加](deploy-action-cfn-adding.md) + [AWS CDK 「デプロイ」アクションの追加](cdk-dep-action-add.md) + [AWS CDK 「ブートストラップ」アクションの追加](cdk-boot-action-add.md) + [「Amazon S3 発行」アクションの追加](s3-pub-action-add.md) + [AWS Lambda 「呼び出し」アクションの追加](lam-invoke-action-add.md) + [「Amazon ECS タスク定義のレンダリング」アクションの追加](render-ecs-action-add.md) [CodeCatalyst Labs アクション](workflows-actions.md#workflows-actions-types-cc-labs)を追加する手順については、以下を参照してください。 + アクションの readme。アクションカタログでアクションの名前を選択することで readme を確認できます。 [GitHub Actions](workflows-actions.md#workflows-actions-types-github) を追加する手順については、以下を参照してください。 + [GitHub Actions との統合](integrations-github-actions.md) [サードパーティーアクション](workflows-actions.md#workflows-actions-types-3p)を追加する手順については、以下を参照してください。 + アクションの readme。アクションカタログでアクションの名前を選択することで readme を確認できます。 1. (任意) **[検証]** を選択して、YAML コードが有効であることを確認します。 1. **[コミット]** を選択して変更をコミットします。 # ワークフローからのアクションの削除ワークフローからアクションを削除するには、次の手順に従います。 ------ #### [ Visual ] **ビジュアルエディタを使用してアクションを削除するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図の削除するアクションで、縦三点アイコン (![\[Ellipsis.\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/elipsis.png))、**[削除]** の順に選択します。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用してアクションを削除するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 削除するアクションを含む YAML のセクションを見つけます。セクションを選択し、キーボードの Delete キーを押します。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # カスタムアクションの開発 CodeCatalyst アクション開発キット (ADK) を使用して、ワークフローで使用するカスタムアクションを開発できます。その後、アクションを CodeCatalyst アクションカタログに公開して、他の CodeCatalyst ユーザーがワークフローでアクションを表示および使用できるようにします。 **アクションを開発、テスト、公開するには (概要レベルのタスク)** 1. アクションの開発に必要なツールとパッケージをインストールします。 1. アクションコードを保存する CodeCatalyst リポジトリを作成します。 1. アクションを初期化します。これにより、独自のコードで更新できるアクション定義ファイル (`action.yml`) など、アクションに必要なソースファイルが作成されます。 1. アクションコードをブートストラップして、アクションプロジェクトを構築、テスト、リリースするために必要なツールとライブラリを取得します。 1. ローカルコンピューターでアクションを構築し、CodeCatalyst リポジトリに変更をプッシュします。 1. ユニットテストでアクションをローカルでテストし、CodeCatalyst で ADK 生成ワークフローを実行します。 1. CodeCatalyst コンソールで **[公開]** ボタンを選択して、CodeCatalyst アクションカタログにアクションを公開します。詳細な手順については、[Amazon CodeCatalyst アクション開発キットデベロッパーガイド](https://docs.aws.amazon.com/codecatalyst/latest/adk/what-is-action-development-kit.html)を参照してください。 # アクショングループへのアクションのグループ化 *アクショングループ*には 1 つ以上のアクションが含まれています。アクションをアクショングループにグループ化すると、ワークフローを整理するのに役立ち、異なるグループ間の依存関係を構成できるようになります。 **注記** 他のアクショングループまたはアクション内にアクショングループをネストすることはできません。 **Topics** + [ ## アクショングループの定義 ](#workflows-define-action-group) + [ # 例: 2 つのアクショングループの定義 ](workflows-group-actions-example.md) ## アクショングループの定義 CodeCatalyst アクショングループを定義するには、次の手順に従います。 ------ #### [ Visual ] *利用できません。[YAML] を選択して YAML の手順を表示してください。* ------ #### [ YAML ] **グループを定義にするには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. `Actions` で次のようなコードを追加します。 ``` Actions: action-group-name: Actions: action-1: Identifier: aws/build@v1 Configuration: ... action-2: Identifier: aws/build@v1 Configuration: ... ``` 別の例については、「[例: 2 つのアクショングループの定義](workflows-group-actions-example.md)」を参照してください。詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」の「[アクション](workflow-reference.md#actions-reference)」にある `action-group-name` プロパティの説明を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 例: 2 つのアクショングループの定義次の例は、`BuildAndTest` と `Deploy` という 2 つの Amazon CodeCatalyst アクショングループを定義する方法を示したものです。`BuildAndTest` グループには 2 つのアクション (`Build` と `Test`) が含まれており、`Deploy` グループには 2 つのアクション (`DeployCloudFormationStack` と `DeployToECS`) も含まれています。 ``` Actions: BuildAndTest: # Action group 1 Actions: Build: Identifier: aws/build@v1 Configuration: ... Test: Identifier: aws/managed-test@v1 Configuration: Deploy: #Action group 2 Actions: DeployCloudFormationStack: Identifier: aws/cfn-deploy@v1 Configuration: ... DeployToECS: Identifier: aws/ecs-deploy@v1 Configuration: ... ``` # アクションの順序付けデフォルトでは、ワークフローにアクションを追加すると、[ビジュアルエディタ](workflow.md#workflow.editors)に横並びで追加されます。つまり、ワークフロー実行を開始すると、アクションが並行して実行されます。アクションを順番に実行する (ビジュアルエディタに縦方向に表示される) 場合は、アクション間に依存関係を設定する必要があります。例えば、ビルドアクションの後にテストアクションが実行されるように、`Build` アクションに依存する `Test` アクションを設定できます。アクションとアクショングループ間の依存関係を設定できます。1 対多の依存関係を構成して、1 つのアクションの開始を他のいくつかのアクションに依存させることもできます。「[アクション間の依存関係の設定](workflows-depends-on-set-up.md)」のガイドラインを参照して、依存関係の設定がワークフローの YAML 構文に準拠していることを確認してください。 **Topics** + [ # アクション間の依存関係を構成する方法の例 ](workflows-depends-on-examples.md) + [ # アクション間の依存関係の設定 ](workflows-depends-on-set-up.md) # アクション間の依存関係を構成する方法の例次の例は、ワークフロー定義ファイル内のアクションとグループ間の依存関係を構成する方法を示したものです。 **Topics** + [ ## 例: 単純な依存関係の構成 ](#workflows-depends-on-example-simple) + [ ## 例: アクションに依存するようにアクショングループを構成する ](#workflows-depends-on-example-action-groups-actions) + [ ## 例: 別のアクショングループに依存するようにアクショングループを構成する ](#workflows-depends-on-example-two-action-groups) + [ ## 例: 複数のアクションに依存するようにアクショングループを構成する ](#workflows-depends-on-example-advanced) ## 例: 単純な依存関係の構成次の例は、`DependsOn` プロパティを使用して `Build` アクションに依存するように `Test` アクションを構成する方法を示したものです。 ``` Actions: Build: Identifier: aws/build@v1 Configuration: ... Test: DependsOn: - Build Identifier: aws/managed-test@v1 Configuration: ... ``` ## 例: アクションに依存するようにアクショングループを構成する次の例は、`FirstAction` アクションに依存するように `DeployGroup` アクショングループを構成する方法を示したものです。アクションとアクショングループが同じレベルにあることに注目してください。 ``` Actions: FirstAction: #An action outside an action group Identifier: aws/github-actions-runner@v1 Configuration: ... DeployGroup: #An action group containing two actions DependsOn: - FirstAction Actions: DeployAction1: ... DeployAction2: ... ``` ## 例: 別のアクショングループに依存するようにアクショングループを構成する次の例は、`BuildAndTestGroup` アクショングループに依存するように `DeployGroup` アクショングループを構成する方法を示したものです。アクショングループが同じレベルにあることに注目してください。 ``` Actions: BuildAndTestGroup: # Action group 1 Actions: BuildAction: ... TestAction: ... DeployGroup: #Action group 2 DependsOn: - BuildAndTestGroup Actions: DeployAction1: ... DeployAction2: ... ``` ## 例: 複数のアクションに依存するようにアクショングループを構成する次の例は、`FirstAction` アクションと `SecondAction` アクションに加え、`BuildAndTestGroup` アクショングループに依存するように `DeployGroup` アクショングループを構成する方法を示したものです。`DeployGroup` が `FirstAction`、`SecondAction`、`BuildAndTestGroup` と同じレベルにあることに注目してください。 ``` Actions: FirstAction: #An action outside an action group ... SecondAction: #Another action ... BuildAndTestGroup: #Action group 1 Actions: Build: ... Test: ... DeployGroup: #Action group 2 DependsOn: - FirstAction - SecondAction - BuildAndTestGroup Actions: DeployAction1: ... DeployAction2: ... ``` # アクション間の依存関係の設定次の手順に従って、ワークフロー内のアクション間の依存関係を設定します。依存関係を構成するときは、次のガイドラインに従ってください。 + アクションがグループ内にある場合、そのアクションは同じグループ内の他のアクションにのみ依存できます。 + アクションとアクショングループは、YAML 階層内で*同じレベル*の他のアクションとアクショングループに依存できますが、別のレベルでは依存*できません*。 ------ #### [ Visual ] **ビジュアルエディタを使用して依存関係を設定するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、別のアクションに依存するアクションを選択します。 1. **[入力]** タブを選択します。 1. **[依存 - オプション]** で以下を実行します。このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して依存関係を設定するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 別のアクションに依存するアクションで、次のようなコードを追加します。 ``` action-name: DependsOn: - action-1 ``` その他の例については、「[アクション間の依存関係を構成する方法の例](workflows-depends-on-examples.md)」を参照してください。一般的なガイドラインについては、「[アクション間の依存関係の設定](#workflows-depends-on-set-up)」を参照してください。詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」の `DependsOn` プロパティの説明を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # アクション間でのアーティファクトとファイルの共有 *アーティファクト*はワークフローアクションの出力であり、通常はフォルダまたはファイルのアーカイブで構成されます。アーティファクトは、アクション間でのファイルや情報の共有を可能にするため重要です。 `sam-template.yml` ファイルを*生成*するビルドアクションがあっても、デプロイアクションでそれを*使用*するようにしたい場合を考えてみましょう。このシナリオでは、アーティファクトを使用して、ビルドアクションが `sam-template.yml` ファイルをデプロイアクションと共有できるようにします。コードは次のようになります。 ``` Actions: BuildAction: Identifier: aws/build@v1 Steps: - Run: sam package --output-template-file sam-template.yml Outputs: Artifacts: - Name: MYARTIFACT Files: - sam-template.yml DeployAction: Identifier: aws/cfn-deploy@v1 Inputs: Artifacts: - MYARTIFACT Configuration: template: sam-template.yml ``` 前のコードでは、ビルドアクション (`BuildAction`) が `sam-template.yml` ファイルを生成し、それを `MYARTIFACT` という出力アーティファクトに追加します。後続のデプロイアクション (`DeployAction`) では、`MYARTIFACT` を入力として指定し、`sam-template.yml` ファイルへのアクセスを許可します。 **Topics** + [ ## アーティファクトを出力や入力として指定せずに共有できますか? ](#workflows-working-artifacts-share) + [ ## ワークフロー間でアーティファクトを共有できますか? ](#workflows-working-artifacts-share-wf) + [ # アーティファクトの例 ](workflows-working-artifacts-ex.md) + [ # 出力アーティファクトの定義 ](workflows-working-artifacts-output.md) + [ # 入力アーティファクトの定義 ](workflows-working-artifacts-refer.md) + [ # アーティファクト内のファイルの参照 ](workflows-working-artifacts-refer-files.md) + [ # アーティファクトのダウンロード ](workflows-download-workflow-outputs.md) ## アーティファクトを出力や入力として指定せずに共有できますか? はい。アクションの YAML コードの `Outputs` および `Inputs` セクションでアーティファクトを指定せずに、アクション間でアーティファクトを共有できます。これを行うには、コンピューティング共有を有効にする必要があります。コンピューティング共有と、コンピューティング共有が有効になっているときにアーティファクトを指定する方法の詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。 **注記** コンピューティング共有機能では、`Outputs` および `Inputs` セクションが不要になることで、ワークフローの YAML コードを簡素化できますが、この機能には有効にする前に注意すべき制限があります。制限の詳細については、「[コンピューティング共有に関する考慮事項](compute-sharing.md#compare-compute-sharing)」を参照してください。 ## ワークフロー間でアーティファクトを共有できますか? いいえ。異なるワークフロー間でアーティファクトを共有することはできませんが、同じワークフロー内のアクション間でアーティファクトを共有することはできます。 # アーティファクトの例次の例は、Amazon CodeCatalyst ワークフロー定義ファイルでアーティファクトを出力、入力、参照する方法を示しています。 **Topics** + [ ## 例: アーティファクトの出力 ](#workflows-working-artifacts-ex-basic) + [ ## 例: 別のアクションによって生成されたアーティファクトの入力 ](#workflows-working-artifacts-ex-ref) + [ ## 例: 複数のアーティファクトでのファイルの参照 ](#workflows-working-artifacts-ex-ref-file) + [ ## 例: 1 つのアーティファクトでのファイルの参照 ](#workflows-working-artifacts-ex-ref-file-one) + [ ## 例: WorkflowSource が存在するときのアーティファクト内のファイルの参照 ](#workflows-working-artifacts-ex-ref-file-wf-source) + [ ## 例: アクショングループが存在するときのアーティファクト内のファイルの参照 ](#workflows-working-artifacts-ex-groups) ## 例: アーティファクトの出力次の例は、2 つの .jar ファイルを含むアーティファクトを出力する方法を示しています。 ``` Actions: Build: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ARTIFACT1 Files: - build-output/file1.jar - build-output/file2.jar ``` ## 例: 別のアクションによって生成されたアーティファクトの入力次の例は、`BuildActionA` で `ARTIFACT4` というアーティファクトを出力し、`BuildActionB` に入力する方法を示しています。 ``` Actions: BuildActionA: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ARTIFACT4 Files: - build-output/file1.jar - build-output/file2.jar BuildActionB: Identifier: aws/build@v1 Inputs: Artifacts: - ARTIFACT4 Configuration: ``` ## 例: 複数のアーティファクトでのファイルの参照次の例は、`BuildActionC` で `ART5` と `ART6` という名前の 2 つのアーティファクトを出力し、`BuildActionD` (`Steps` の下) で `file5.txt` (アーティファクト `ART5` 内) と `file6.txt` (アーティファクト `ART6` 内) という名前の 2 つのファイルを参照する方法を示しています。 **注記** ファイルの参照の詳細については、「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 **注記** この例では `$CATALYST_SOURCE_DIR_ART5` プレフィックスが使用されていますが、こちらは省略しても構いません。これは、 `ART5` が*プライマリ入力*であるためです。プライマリ入力の詳細については、「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 ``` Actions: BuildActionC: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART5 Files: - build-output/file5.txt - Name: ART6 Files: - build-output/file6.txt BuildActionD: Identifier: aws/build@v1 Inputs: Artifacts: - ART5 - ART6 Configuration: Steps: - run: cd $CATALYST_SOURCE_DIR_ART5/build-output && cat file5.txt - run: cd $CATALYST_SOURCE_DIR_ART6/build-output && cat file6.txt ``` ## 例: 1 つのアーティファクトでのファイルの参照次の例は、`BuildActionE` で `ART7` という名前の 1 つのアーティファクトを出力し、`BuildActionF` (`Steps` の下) で `file7.txt` (アーティファクト `ART7` 内) を参照する方法を示しています。参照では、「[例: 複数のアーティファクトでのファイルの参照](#workflows-working-artifacts-ex-ref-file)」で行ったように `build-output` ディレクトリの前に `$CATALYST_SOURCE_DIR_`*アーティファクト名*プレフィックスが必要でないことに注意してください。これは、`Inputs` で指定された項目が 1 つだけであるためです。 **注記** ファイルの参照の詳細については、「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 ``` Actions: BuildActionE: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART7 Files: - build-output/file7.txt BuildActionF: Identifier: aws/build@v1 Inputs: Artifacts: - ART7 Configuration: Steps: - run: cd build-output && cat file7.txt ``` ## 例: WorkflowSource が存在するときのアーティファクト内のファイルの参照次の例は、`BuildActionG` で `ART8` という名前の 1 つのアーティファクトを出力し、`BuildActionH` (`Steps` の下) で `file8.txt` (アーティファクト `ART8` 内) を参照する方法を示しています。参照では、「[例: 複数のアーティファクトでのファイルの参照](#workflows-working-artifacts-ex-ref-file)」で行ったように `$CATALYST_SOURCE_DIR_`*アーティファクト名*プレフィックスが必要であることに注意してください。これは、`Inputs` (ソースとアーティファクト) で複数の項目が指定されているため、ファイルを検索する場所を示すプレフィックスが必要となるためです。 **注記** ファイルの参照の詳細については、「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 ``` Actions: BuildActionG: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART8 Files: - build-output/file8.txt BuildActionH: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Artifacts: - ART8 Configuration: Steps: - run: cd $CATALYST_SOURCE_DIR_ART8/build-output && cat file8.txt ``` ## 例: アクショングループが存在するときのアーティファクト内のファイルの参照次の例は、`ActionGroup1`、`ActionI` で `ART9` という名前のアーティファクトを出力し、`ActionJ` で `file9.txt` (アーティファクト `ART9` 内) を参照する方法を示しています。ファイルの参照の詳細については、「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 ``` Actions: ActionGroup1: Actions: ActionI: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ART9 Files: - build-output/file9.yml ActionJ: Identifier: aws/cfn-deploy@v1 Inputs: Sources: - WorkflowSource Artifacts: - ART9 Configuration: template: /artifacts/ActionGroup1@ActionJ/ART9/build-output/file9.yml ``` # 出力アーティファクトの定義次の手順に従って、Amazon CodeCatalyst アクションで出力するアーティファクトを定義します。その後、このアーティファクトは他のアクションで使用できるようになります。 **注記** すべてのアクションが出力アーティファクトをサポートしているわけではありません。アクションが出力アーティファクトをサポートしているかどうかを確認するには、以下のビジュアルエディタの手順を実行して、アクションの **[出力]** タブに **[出力アーティファクト]** ボタンが含まれているかどうかを確認します。含まれている場合は出力アーティファクトがサポートされています。 ------ #### [ Visual ] **ビジュアルエディタを使用して出力アーティファクトを定義するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、アーティファクトを生成するアクションを選択します。 1. **[出力]** タブを選択します。 1. **[アーティファクト]** で **[アーティファクトの追加]** を選択します。 1. **[アーティファクトの追加]** を選択し、次のようにフィールドに情報を入力します。 **アーティファクト名を構築** アクションによって生成されるアーティファクトの名前を指定します。アーティファクト名はワークフロー内で一意でなければならず、英数字 (a～z、A～Z、0～9) とアンダースコア (\$1) しか使用できません。スペース、ハイフン (-)、その他の特殊文字は使用できません。引用符を使用して、出力アーティファクト名でスペース、ハイフン、その他の特殊文字を有効にすることはできません。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **構築で生成されるファイル** CodeCatalyst がアクションによって出力されるアーティファクトに含めるファイルを指定します。これらのファイルは、実行時にワークフローアクションによって生成され、ソースリポジトリでも使用できます。ファイルパスは、ソースリポジトリまたは前のアクションからのアーティファクトに設定でき、ソースリポジトリまたはアーティファクトルートを基準とすることができます。glob パターンを使用してパスを指定できます。例: + ビルドまたはソースリポジトリの場所のルートにある 1 つのファイルを指定するには、`my-file.jar` を使用します。 + サブディレクトリ内の 1 つのファイルを指定するには、`directory/my-file.jar` または `directory/subdirectory/my-file.jar` を使用します。 + すべてのファイルを指定するには、`"**/*"` を使用します。glob パターン `**` は、任意の数のサブディレクトリにマッチすることを示します。 + `directory` という名前のディレクトリ内のすべてのファイルとディレクトリを指定するには、`"directory/**/*"` を使用します。glob パターン `**` は、任意の数のサブディレクトリにマッチすることを示します。 + `directory` という名前のディレクトリ内のすべてのファイルを指定するが、そのサブディレクトリを含めないようにするには、`"directory/*"` を使用します。 **注記** ファイルパスに 1 つ以上のアスタリスク (`*`) またはその他の特殊文字が含まれている場合は、パスを二重引用符 (`""`) で囲みます。特殊文字の詳細については、「[構文ガイドラインと規則](workflow-reference.md#workflow.terms.syntax.conv)」を参照してください。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **注記** 場合によっては、ファイルパスにプレフィックスを追加して、どのアーティファクトまたはソースにあるのかを示す必要があります。詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」および「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して出力アーティファクトを定義するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ワークフローアクションで、次のようなコードを追加します。 ``` action-name: Outputs: Artifacts: - Name: artifact-name Files: - file-path-1 - file-path-2 ``` その他の例については、「[アーティファクトの例](workflows-working-artifacts-ex.md)」を参照してください。詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 入力アーティファクトの定義別の Amazon CodeCatalyst アクションによって生成されたアーティファクトを使用する場合は、現在のアクションへの入力としてアーティファクトを指定する必要があります。複数のアーティファクトを入力として指定できる場合があります。これはアクションによって異なります。詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 他のワークフローのアーティファクトを参照することはできません。次の手順に従って、別のアクションからのアーティファクトを現在のアクションへの入力として指定します。 **前提条件** 開始する前に、他のアクションからアーティファクトを出力済みであることを確認してください。詳細については、「[出力アーティファクトの定義](workflows-working-artifacts-output.md)」を参照してください。アーティファクトを出力すると、他のアクションで使用できるようになります。 ------ #### [ Visual ] **アクションへの入力としてアーティファクトを指定するには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、アーティファクトを入力として指定するアクションを選択します。 1. **[入力]** を選択します。 1. **[アーティファクト - 省略可**] で以下を実行します。このアクションへの入力として提供する以前のアクションのアーティファクトを指定します。これらのアーティファクトは、前のアクションで出力アーティファクトとして既に定義されている必要があります。入力アーティファクトを指定しない場合は、`action-name/Inputs/Sources` で少なくとも 1 つのソースリポジトリを指定する必要があります。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **注記** **[アーティファクト - オプション]** のドロップダウンリストが使用できない場合 (ビジュアルエディタ)、または YAML の検証時にエラーが発生する場合 (YAML エディタ)、アクションが 1 つの入力のみをサポートしていることが原因である可能性があります。この場合はソース入力を削除してみてください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **アクションへの入力としてアーティファクトを指定するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. アーティファクトを入力として指定するアクションで、次のようなコードを追加します。 ``` action-name: Inputs: Artifacts: - artifact-name ``` その他の例については、「[アーティファクトの例](workflows-working-artifacts-ex.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # アーティファクト内のファイルの参照アーティファクト内に存在するファイルがあり、Amazon CodeCatalyst ワークフローアクションのいずれかでこのファイルを参照する必要がある場合は、次の手順を実行します。 **注記** [ソースリポジトリファイルの参照](workflows-sources-reference-files.md) も参照してください。 ------ #### [ Visual ] *利用できません。YAML を選択して YAML の手順を表示してください。* ------ #### [ YAML ] **アーティファクト内のファイルを参照するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ファイルを参照するアクションで、次のようなコードを追加します。 ``` Actions: My-action: Inputs: Sources: - WorkflowSource Artifacts: - artifact-name Configuration: template: artifact-path/path/to/file.yml ``` 前のコードで以下を置き換えます。 + *artifact-name* をアーティファクトの名前に置き換えます。 + *artifact-path* を以下の表の値に置き換えます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/workflows-working-artifacts-refer-files.html) 例については「[アーティファクトの例](workflows-working-artifacts-ex.md)」を参照してください。 **注記** 次の場合は、*artifact-path* を省略し、アーティファクトルートディレクトリを基準にしたファイルパスを指定するだけで構いません。参照を含めるアクションには、`Inputs` の下に 1 つの項目のみが含まれます (例えば、1 つの入力アーティファクトが含まれ、ソースは含まれません)。参照するファイルはプライマリ入力にあります。*プライマリ入力*は `WorkflowSource` であるか、`WorkflowSource` がない場合はリストされた最初の入力アーティファクトです。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # アーティファクトのダウンロードトラブルシューティングの目的で、Amazon CodeCatalyst ワークフローアクションによって生成されたアーティファクトをダウンロードして検査できます。ダウンロードできるアーティファクトは次の 2 種類です。 + **ソースアーティファクト** – 実行開始時に存在していたソースリポジトリコンテンツのスナップショットを含むアーティファクト。 + **ワークフローアーティファクト** – ワークフローの構成ファイルの `Outputs` プロパティで定義されているアーティファクト。 **ワークフローによって出力されたアーティファクトをダウンロードするには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. ワークフローの名前の下で **[実行]** を選択します。 1. **[実行履歴]** の **[実行 ID]** 列で実行を選択します。例えば、`Run-95a4d`。 1. 実行の名前の下で **[アーティファクト]** を選択します。 1. アーティファクトの横にある **[ダウンロード]** を選択します。アーカイブファイルがダウンロードされます。ファイル名はランダムな 7 文字で構成されます。 1. 任意のアーカイブ抽出ユーティリティを使用してアーカイブを抽出します。 # 使用するアクションバージョンの指定デフォルトでは、ワークフローにアクションを追加すると、Amazon CodeCatalyst は次の形式を使用してワークフロー定義ファイルにフルバージョンを追加します。 `vmajor.minor.patch` 例えば、次のようになります。 ``` My-Build-Action: Identifier: aws/build@v1.0.0 ``` `Identifier` プロパティのフルバージョンを短縮して、ワークフローが常にアクションの最新のマイナーバージョンまたはパッチバージョンを使用するようにすることができます。例えば、次のように指定したとします。 ``` My-CloudFormation-Action: Identifier: aws/cfn-deploy@v1.0 ``` この場合、最新パッチバージョンは `1.0.4` で、その後、アクションでは `1.0.4` を使用します。例えば `1.0.5` という後続のバージョンがリリースされると、アクションでは `1.0.5` を使用します。例えば `1.1.0` というマイナーバージョンがリリースされると、アクションでは引き続き `1.0.5` を使用します。バージョンを指定する詳細な手順については、以下のトピックのいずれかを参照してください。次の手順に従って、ワークフローで使用するアクションのバージョンを指定します。最新のメジャー/マイナーバージョン、または特定のパッチバージョンを指定できます。アクションの最新のマイナーバージョンまたはパッチバージョンを使用することをお勧めします。 ------ #### [ Visual ] *利用できません。YAML を選択して YAML の手順を表示してください。* ------ #### [ YAML ] **アクションの最新バージョンまたは特定のパッチバージョンを使用するようにワークフローを構成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. バージョンを編集するアクションを見つけます。 1. アクションの `Identifier` プロパティを見つけ、バージョンを次のいずれかに設定します。 + action-identifier@v*major* – ワークフローで特定のメジャーバージョンを使用するようにし、最新のマイナーバージョンとパッチバージョンを自動的に選択できるようにするにはこの構文を使用します。 + action-identifier@v*major*.*minor* – ワークフローで特定のマイナーバージョンを使用するようにし、最新のパッチバージョンを自動的に選択できるようにするにはこの構文を使用します。 + action-identifier@v*major*.*minor*.*patch* – ワークフローで特定のパッチバージョンを使用するようにするにはこの構文を使用します。 **注記** 利用可能なバージョンが不明な場合は、「[使用可能なアクションバージョンの一覧表示](workflows-action-versions-determine.md)」を参照してください。 **注記** メジャーバージョンを省略することはできません。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 使用可能なアクションバージョンの一覧表示次の手順に従って、ワークフローで使用できるアクションのバージョンを確認します。 ------ #### [ Visual ] **使用可能なアクションバージョンを確認するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. バージョンを表示するアクションを見つけます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択するか、ワークフローを作成します。ワークフローの作成については、「[ワークフローの作成](workflows-create-workflow.md)」を参照してください。 1. **[編集]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[Amazon CodeCatalyst]** を選択し、CodeCatalyst、CodeCatalyst Labs、サードパーティーのアクションを表示するか、**[GitHub]** を選択して厳選された GitHub アクションを表示します。 1. アクションを検索し、その名前を選択します。プラス記号 (**\$1**) は選択しないでください。アクションの詳細が表示されます。 1. アクションの詳細ダイアログボックスの右上付近で、**[バージョン]** ドロップダウンリストを選択して、使用可能なアクションのバージョンのリストを表示します。 ------ #### [ YAML ] *利用できません。「ビジュアル」を選択してビジュアルエディタの手順を表示してください。* ------ # アクションのソースコードの表示アクションのソースコードを表示して、リスクの高いコード、セキュリティの脆弱性、またはその他の欠陥が含まれていないことを確認できます。次の手順に従って、[CodeCatalyst](workflows-actions.md#workflows-actions-types-cc)、[CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs)、または[サードパーティー](workflows-actions.md#workflows-actions-types-3p)アクションのソースコードを表示します。 **注記** [GitHub Action](workflows-actions.md#workflows-actions-types-github) のソースコードを表示するには、[GitHub Marketplace](https://github.com/marketplace/actions) のアクションのページに移動します。このページには、アクションのソースコードを見つけることができるアクションのリポジトリへのリンクがあります。 **注記** CodeCatalyst アクションである[ビルド](build-workflow-actions.md)、[テスト](test-workflow-actions.md)、[GitHub Actions](integrations-github-action-add.md) のソースコードを表示することはできません。 **注記** AWS は、GitHub Actions またはサードパーティーのアクションのアクションコードをサポートまたは保証しません。 **アクションのソースコードを表示するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. コードを表示するアクションを見つけます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択するか、ワークフローを作成します。ワークフローの作成については、「[ワークフローの作成](workflows-create-workflow.md)」を参照してください。 1. **[編集]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[Amazon CodeCatalyst]** を選択し、CodeCatalyst、CodeCatalyst Labs、およびサードパーティーのアクションを表示します。 1. アクションを検索し、その名前を選択します。プラス記号 (**\$1**) は選択しないでください。アクションの詳細が表示されます。 1. アクションの詳細ダイアログボックスの下部近くで **[ダウンロード]** を選択します。アクションのソースコードが存在する Amazon S3 バケットを示すページが表示されます。Amazon S3 の詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[Amazon S3 とは](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)」を参照してください。 1. コードを調べて、品質とセキュリティに対する要件を満たしていることを確認します。 # GitHub Actions との統合 *GitHub Action* は [CodeCatalyst アクション](workflows-actions.md#workflows-actions-types-cc) とよく似ていますが、GitHub ワークフローで使用できるように開発されているという点が異なります。GitHub Actions の詳細については、[GitHub Actions](https://docs.github.com/en/actions) ドキュメントを参照してください。 GitHub Actions は、CodeCatalyst ワークフローのネイティブ CodeCatalyst アクションと併せて使用できます。 GitHub Action を CodeCatalyst ワークフローに追加するには、次の 2 つの方法があります。 + CodeCatalyst コンソールで、キュレートされたリストから GitHub Action を選択できます。いくつかのよく使用されている GitHub Actions が利用可能です。詳細については、「[キュレートされた GitHub Action を追加する](integrations-github-action-add-curated.md)」を参照してください。 + 使用したい GitHub Action が CodeCatalyst コンソールで利用できない場合は、**GitHub Actions** アクションを使用して追加できます。 ***GitHub Actions*** アクションとは、*CodeCatalyst* ワークフローと互換性を持たせるために GitHub Action をラップする CodeCatalyst アクションです。次の例は、[Super-Linter](https://github.com/marketplace/actions/super-linter) GitHub Action をラップする **GitHub Actions** を示しています。 ``` Actions: GitHubAction: Identifier: aws/github-actions-runner@v1 Configuration: Steps: - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: "true" DEFAULT_BRANCH: main ``` 前のコードでは、CodeCatalyst **GitHub Actions** アクション (`aws/github-actions-runner@v1` で識別される) は Super-Linter アクション (`github/super-linter@v4` で識別される) をラップし、CodeCatalyst ワークフローで機能するようにしています。詳細については、「[GitHub Actions アクションを追加する](integrations-github-action-add.md)」を参照してください。上記の例に示したように、すべての GitHub Actions は、キュレートされているものもされていないものも、**GitHub Actions** アクション (`aws/github-actions-runner@v1`) 内にラップされていなければなりません。アクションが正しく機能するには、ラッパーが必要です。 **Topics** + [ ## GitHub Actions と CodeCatalyst アクションの違い ](#integrations-github-actions-how-different) + [ ## GitHub Actions はワークフロー内の他の CodeCatalyst アクションとやりとりできますか? ](#integrations-github-actions-interactions.title) + [ ## どの GitHub Actions を使用できますか? ](#integrations-github-actions-supported) + [ ## CodeCatalyst における GitHub Action の制限事項 ](#integrations-github-actions-limitations) + [ ## GitHub Action を追加する大まかな手順 ](#integrations-github-actions-how-to) + [ ## GitHub Action は GitHub で実行されますか? ](#integrations-github-actions-where-it-runs) + [ ## GitHub ワークフローを使用することもできますか? ](#integrations-github-actions-workflows-support.title) + [ ## GitHub Actions アクションで使用されるランタイムイメージ ](#integrations-github-actions-runtime) + [ # チュートリアル: GitHub Action を使用した lint コード ](integrations-github-action-tutorial.md) + [ # GitHub Actions アクションを追加する ](integrations-github-action-add.md) + [ # キュレートされた GitHub Action を追加する ](integrations-github-action-add-curated.md) + [ # GitHub 出力パラメータをエクスポートする ](integrations-github-action-export.md) + [ # GitHub 出力パラメータを参照する ](integrations-github-action-referencing.md) + [ # GitHub Actions アクション YAML ](github-action-ref.md) ## GitHub Actions と CodeCatalyst アクションの違い CodeCatalyst ワークフロー内で使用される GitHub Actions には、CodeCatalyst アクションと同じレベルのアクセス AWS と CodeCatalyst 機能 ([環境](deploy-environments.md)や[問題](issues.md)など) との統合はありません。 CodeCatalyst ## GitHub Actions はワークフロー内の他の CodeCatalyst アクションとやりとりできますか? はい。例えば、GitHub Actions は、他の CodeCatalyst アクションによって生成された変数を入力として使用でき、出力パラメータとアーティファクトを CodeCatalyst アクションと共有することもできます。詳細については、「[GitHub 出力パラメータをエクスポートする](integrations-github-action-export.md)」および「[GitHub 出力パラメータを参照する](integrations-github-action-referencing.md)」を参照してください。 ## どの GitHub Actions を使用できますか? CodeCatalyst コンソールから利用可能な任意の GitHub Action、および [GitHub Marketplace](https://github.com/marketplace/actions) で利用可能な任意の GitHub Action を使用できます。Marketplace の GitHub Action を使用する場合は、以下の[制限](#integrations-github-actions-limitations)に注意してください。 ## CodeCatalyst における GitHub Action の制限事項 + GitHub Actions は CodeCatalyst [Lambda コンピューティングタイプ](workflows-working-compute.md#compute.types)で使用できません。 + GitHub Actions は [2022 年 11 月](build-images.md#build.previous-image)のランタイム環境 Docker イメージで実行されており、このイメージには古いツールが含まれています。イメージやツールの詳細については、「[ランタイム環境イメージの指定](build-images.md)」を参照してください。 + [`github` コンテキスト](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context)に内部的に依存する GitHub Actions や、GitHub 固有のリソースを参照する GitHub Actions は、CodeCatalyst ではサポートされていません。例えば、次のアクションは CodeCatalyst では機能しません。 + GitHub リソースを追加、変更、または更新しようとするアクション。例としては、プルリクエストを更新するアクション、GitHub で問題を作成するアクションなどがあります。 + [https://github.com/actions](https://github.com/actions) にリストされているほぼすべてのアクション。 + [Docker コンテナアクション](https://docs.github.com/en/actions/creating-actions/about-custom-actions#docker-container-actions)である GitHub Actions は機能しますが、デフォルトの Docker ユーザー (root) で実行する必要があります。ユーザー 1001 としてアクションを実行しないでください (本文執筆時点では、ユーザー 1001 は GitHub で機能しますが、CodeCatalyst では機能しません)。詳細については、「[GitHub Actions のための Dockerfile サポート](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions)」で「[User](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user)」トピックを参照してください。 CodeCatalyst コンソールで利用可能な GitHub Actions の一覧については、「[キュレートされた GitHub Action を追加する](integrations-github-action-add-curated.md)」を参照してください。 ## GitHub Action を追加する大まかな手順 GitHub Action を CodeCatalyst ワークフローに追加する大まかな手順は次のとおりです。 1. CodeCatalyst プロジェクトで、**ワークフローを作成します**。ワークフローでは、アプリケーションをビルド、テスト、デプロイする方法を定義します。詳細については、「[初めてのワークフロー](workflows-getting-started.md)」を参照してください。 1. ワークフローで、**キュレートされた GitHub Action を追加する**か、**GitHub Actions** アクションを追加します。 1. 次のいずれかを行います。 + キュレートされたアクションを追加する場合は、そのアクションを設定します。詳細については、「[キュレートされた GitHub Action を追加する](integrations-github-action-add-curated.md)」を参照してください。 + キュレートされたアクション以外を追加する場合は、**GitHub Actions** アクション内に、**GitHub Action の YAML コードを貼り付けます**。このコードは、[GitHub Marketplace](https://github.com/marketplace/actions) の該当する GitHub Action の詳細ページにあります。CodeCatalyst で動作させるには、おそらくコードを少し変更する必要があります。詳細については、「[GitHub Actions アクションを追加する](integrations-github-action-add.md)」を参照してください。 1. (オプション) ワークフロー内で、ビルドアクションやテストアクションなどの**他のアクションを追加します**。詳細については、「[ワークフローを使用して構築、テスト、デプロイするワークフローを使用して構築、テスト、デプロイする](workflow.md)」を参照してください。 1. **ワークフローの開始**は、手動で行うか、トリガーを介して自動で行います。ワークフローは、GitHub Action とワークフロー内の他のアクションを実行します。詳細については、「[手動でのワークフロー実行の開始](workflows-manually-start.md)」を参照してください。詳細なステップについては、次を参照してください。 + [キュレートされた GitHub Action を追加する](integrations-github-action-add-curated.md). + [GitHub Actions アクションを追加する](integrations-github-action-add.md). ## GitHub Action は GitHub で実行されますか? いいえ。GitHub Action は CodeCatalyst の[ランタイム環境イメージ](workflows-working-compute.md)を使用して CodeCatalyst で実行されます。 ## GitHub ワークフローを使用することもできますか? いいえ。 ## GitHub Actions アクションで使用されるランタイムイメージ CodeCatalyst **GitHub Actions** アクションは、[2022 年 11 月のイメージ](build-images.md#build.previous-image)で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。 # チュートリアル: GitHub Action を使用した lint コードこのチュートリアルでは、Amazon CodeCatalyst ワークフローに [Super-Linter GitHub Action](https://github.com/marketplace/actions/super-linter) を追加します。Super-Linter アクションは、コードを検査し、コードにエラー、フォーマットの問題、疑わしいコンストラクトがある領域を見つけて、その結果を CodeCatalyst コンソールに出力します。ワークフローに linter を追加したら、ワークフローを実行してサンプル Node.js アプリケーション (`app.js`) を lint します。次に、報告された問題を修正し、ワークフローを再度実行して、修正がうまくいったかどうかを確認します。 **ヒント** Super-Linter を使用して、[CloudFormation テンプレート](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)などの YAML ファイルを lint することを検討してください。 **Topics** + [ ## 前提条件 ](#integrations-github-action-tutorial-prereqs) + [ ## ステップ 1: ソースレポジトリを作成する ](#integrations-github-action-tutorial-create-source-repo) + [ ## ステップ 2: app.js ファイルを追加する ](#integrations-github-action-tutorial-add-appjs) + [ ## ステップ 3: Super-Linter アクションを実行するワークフローを作成する ](#integrations-github-action-tutorial-create-workflow) + [ ## ステップ 4: Super-Linter が検出した問題を修正する ](#integrations-github-action-tutorial-fix-probs) + [ ## クリーンアップ ](#integrations-github-action-tutorial-cleanup) ## 前提条件開始するには、以下のものが必要です。 + が接続された CodeCatalyst **スペース** AWS アカウント。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。 + CodeCatalyst スペース内の `codecatalyst-linter-project` という空のプロジェクト。このプロジェクトを作成するには、**[ゼロから開始]** オプションを選択します。 ``` ``` 詳細については、「[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)」を参照してください。 ## ステップ 1: ソースレポジトリを作成するこのステップでは、CodeCatalyst に空のソースリポジトリを作成します。このリポジトリを使用して、このチュートリアルのサンプルアプリケーションソースファイル `app.js` を保存します。ソースリポジトリの詳細については、「[ソースリポジトリを作成する](source-repositories-create.md)」を参照してください。 **ソースリポジトリを作成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクト「`codecatalyst-linter-project`」に移動します。 1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。 1. **[リポジトリの追加]** を選択し、**[リポジトリの作成]** を選択します。 1. **[リポジトリ名]** に次のように入力します。 ``` codecatalyst-linter-source-repository ``` 1. **[作成]** を選択します。 ## ステップ 2: app.js ファイルを追加するこのステップでは、`app.js` ファイルをソースリポジトリに追加します。`app.js` にはいくつかの誤りがある関数コードが含まれており、これが linter によって検出されます。 **app.js ファイルを追加するには** 1. CodeCatalyst コンソールで、プロジェクト `codecatalyst-linter-project` を選択します。 1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。 1. ソースリポジトリのリストから、リポジトリ `codecatalyst-linter-source-repository` を選択します。 1. **[ファイル]** で、**[ファイルを作成]** を選択します。 1. テキストボックスに次のコードを入力します。 ``` // const axios = require('axios') // const url = 'http://checkip.amazonaws.com/'; let response; /** * * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format * @param {Object} event - API Gateway Lambda Proxy Input Format * * Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html * @param {Object} context * * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html * @returns {Object} object - API Gateway Lambda Proxy Output Format * */ exports.lambdaHandler = async (event, context) => { try { // const ret = await axios(url); response = { statusCode: 200, 'body': JSON.stringify({ message: 'hello world' // location: ret.data.trim() }) } } catch (err) { console.log(err) return err } return response } ``` 1. **[ファイル名]** に `app.js` と入力します。その他のオプションはデフォルトのままにします。 1. **[コミット]** を選択します。これで、`app.js` と呼ばれる新しいファイルが作成されました。 ## ステップ 3: Super-Linter アクションを実行するワークフローを作成するこのステップでは、ソースリポジトリにコードをプッシュするときに Super-Linter アクションを実行するワークフローを作成します。ワークフローは、YAML ファイルで定義する以下の要素で構成されます。 + **トリガー** – このトリガーは、ソースリポジトリに変更をプッシュすると、ワークフローの実行を自動的に開始します。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + **GitHub Actions アクション** - トリガー時に、**GitHub Actions** アクションは Super-Linter アクションを実行し、ソースリポジトリ内のすべてのファイルを検査します。linter で問題が検出されると、ワークフローアクションは失敗します。 **Super-Linter アクションを実行するワークフローを作成するには** 1. CodeCatalyst コンソールで、プロジェクト `codecatalyst-linter-project` を選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフローを作成]** を選択します。 1. **[ソースリポジトリ]** で、`codecatalyst-linter-source-repository` を選択します。 1. **[ブランチ]** で、`main` を選択します。 1. **[作成]** を選択します。 1. YAML サンプルコードを削除します。 1. 次の YAML を追加します。 ``` Name: codecatalyst-linter-workflow SchemaVersion: "1.0" Triggers: - Type: PUSH Branches: - main Actions: SuperLinterAction: Identifier: aws/github-actions-runner@v1 Configuration: Steps: github-action-code ``` 上記のコードで、この手順の次のステップで指示されているように、*github-action-code* を Super-Linter アクションコードに置き換えます。 1. GitHub Marketplace の [Super-Linter のページ](https://github.com/marketplace/actions/super-linter)に移動します。 1. `steps:` (小文字) の下にあるコードを見つけ、CodeCatalyst ワークフローの `Steps:` (大文字) に貼り付けます。次のコードに示すように、GitHub Action コードを CodeCatalyst の規格に準拠するように調整します。 CodeCatalyst ワークフローは次のようになります。 ``` Name: codecatalyst-linter-workflow SchemaVersion: "1.0" Triggers: - Type: PUSH Branches: - main Actions: SuperLinterAction: Identifier: aws/github-actions-runner@v1 Configuration: Steps: - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: "true" DEFAULT_BRANCH: main ``` 1. (任意) **[検証]** を選択して、コミットする前に YAML コードが有効であることを確認します。 1. **[コミット]** を選択して **[コミットメッセージ]** を入力し、`codecatalyst-linter-source-repository` **[リポジトリ]** を選択して再度 **[コミット]** を選択します。これでワークフローが作成されました。ワークフローの先頭で定義されているトリガーにより、ワークフローの実行が自動的に開始されます。 **ワークフロー実行の進行状況を確認するには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. 先ほど作成したワークフロー `codecatalyst-linter-workflow` を選択します。 1. ワークフロー図で、**SuperLinterAction** を選択します。 1. アクションが失敗するのを待ちます。この失敗は想定されるもので、linter でコードに問題が検出されたためです。 1. CodeCatalyst コンソールを開いたままにして、「[ステップ 4: Super-Linter が検出した問題を修正する](#integrations-github-action-tutorial-fix-probs)」に進みます。 ## ステップ 4: Super-Linter が検出した問題を修正する Super-Linter で、ソースリポジトリに含まれる `README.md` ファイルだけでなく、`app.js`コードにも問題が検出されているはずです。 **linter が見つけた問題を修正するには** 1. CodeCatalyst コンソールで、**[ログ]** タブにある **[lint コードベース]** を選択します。 Super-Linter アクションで生成されたログが表示されます。 1. Super-Linter ログで、問題が始まる 90 行目付近までスクロールダウンします。次のような内容です。 ``` /github/workspace/hello-world/app.js:3:13: Extra semicolon. /github/workspace/hello-world/app.js:9:92: Trailing spaces not allowed. /github/workspace/hello-world/app.js:21:7: Unnecessarily quoted property 'body' found. /github/workspace/hello-world/app.js:31:1: Expected indentation of 2 spaces but found 4. /github/workspace/hello-world/app.js:32:2: Newline required at end of file but not found. ``` 1. ソースリポジトリの `app.js` と `README.md` を修正し、変更をコミットします。 **ヒント** `README.md` を修正するには、次のように `markdown` をコードブロックに追加します。 ``` ```markdown Setup examples: ... ``` ``` 変更により、別のワークフローが自動的に実行されます。ワークフローが終了するのを待ちます。すべての問題を修正すると、ワークフローが成功します。 ## クリーンアップ CodeCatalyst でクリーンアップを行い、このチュートリアルの作業内容を環境から削除します。 **CodeCatalyst でクリーンアップを行うには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. `codecatalyst-linter-source-repository` を削除します。 1. `codecatalyst-linter-workflow` を削除します。このチュートリアルでは、一部のコードを lint するために Super-Linter GitHub Action を CodeCatalyst ワークフローに追加する方法を学習しました。 # GitHub Actions アクションを追加する ***GitHub Actions*** アクションとは、*CodeCatalyst* ワークフローと互換性を持たせるために GitHub Action をラップする CodeCatalyst アクションです。詳細については、「[GitHub Actions との統合](integrations-github-actions.md)」を参照してください。 **GitHub Actions** アクションをワークフローに追加する手順は次のとおりです。 **ヒント** **GitHub Actions** アクションの使用方法を示すチュートリアルについては、「[チュートリアル: GitHub Action を使用した lint コード](integrations-github-action-tutorial.md)」を参照してください。 ------ #### [ Visual ] **ビジュアルエディタを使用して GitHub Actions アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[GitHub]** を選択します。 1. **GitHub Actions** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[GitHub Actions]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[GitHub Actions アクション YAML](github-action-ref.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して GitHub Actions アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[GitHub]** を選択します。 1. **GitHub Actions** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[GitHub Actions]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[GitHub Actions アクション YAML](github-action-ref.md)」に記載されています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ ## GitHub Actions アクションの定義 **GitHub Actions** アクションは、ワークフロー定義ファイル内の一連の YAML プロパティとして定義されます。これらのプロパティの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」の「[GitHub Actions アクション YAML](github-action-ref.md)」を参照してください。 # キュレートされた GitHub Action を追加する *キュレートされた GitHub Action* とは、CodeCatalyst コンソールで利用できる GitHub Action であり、CodeCatalyst ワークフロー内で GitHub Action を使用する方法の例として機能します。キュレートされた GitHub Actions は、`aws/github-actions-runner@v1` 識別子で識別される、CodeCatalyst によって作成された [**GitHub Actions** アクション](integrations-github-action-add.md)でラップされます。例えば、キュレートされた GitHub Action である [TruffleHog OSS](https://github.com/marketplace/actions/trufflehog-oss) は次のようになります。 ``` Actions: TruffleHogOSS_e8: Identifier: aws/github-actions-runner@v1 Inputs: Sources: - WorkflowSource # This specifies that the action requires this Workflow as a source Configuration: Steps: - uses: trufflesecurity/trufflehog@v3.16.0 with: path: ' ' # Required; description: Repository path base: ' ' # Required; description: Start scanning from here (usually main branch). head: ' ' # Optional; description: Scan commits until here (usually dev branch). extra_args: ' ' # Optional; description: Extra args to be passed to the trufflehog cli. ``` 前のコードでは、CodeCatalyst **GitHub Actions** アクション (`aws/github-actions-runner@v1` で識別される) は TruffleHog OSS アクション (`trufflesecurity/trufflehog@v3.16.0` で識別される) をラップし、CodeCatalyst ワークフローで機能するようにしています。このアクションを設定するには、`with:` の下にある空の文字列を実際の値に置き換えます。例えば、次のようになります。 ``` Actions: TruffleHogOSS_e8: Identifier: aws/github-actions-runner@v1 Inputs: Sources: - WorkflowSource # This specifies that the action requires this Workflow as a source Configuration: Steps: - uses: trufflesecurity/trufflehog@v3.16.0 with: path: ./ base: main # Required; description: Start scanning from here (usually main branch). head: HEAD # Optional; description: Scan commits until here (usually dev branch). extra_args: '‐‐debug ‐‐only-verified' # Optional; description: Extra args to be passed to the trufflehog cli. ``` キュレートされた GitHub Action をワークフローに追加する手順は次のとおりです。CodeCatalyst ワークフローでの GitHub Action の使用に関する一般的な情報については、「[GitHub Actions との統合](integrations-github-actions.md)」を参照してください。 **注記** キュレートされたアクションのリストに GitHub Action が表示されない場合は、**GitHub Actions** アクションを使用してワークフローに追加できます。詳細については、「[GitHub Actions アクションを追加する](integrations-github-action-add.md)」を参照してください。 ------ #### [ Visual ] **ビジュアルエディタを使用してキュレートされた GitHub Action を追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[GitHub]** を選択します。 1. GitHub Action を参照または検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + GitHub Action の名前を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]**、**[設定]**、**[出力]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[GitHub Actions アクション YAML](github-action-ref.md)」を参照してください。このリファレンスでは、**GitHub Actions** アクションで利用可能な各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。キュレートされた GitHub Action で使用できる設定オプションについては、該当するドキュメントを参照してください。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用してキュレートされた GitHub アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから **[GitHub]** を選択します。 1. GitHub Action を参照または検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + GitHub Action の名前を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。**GitHub Actions** アクションで使用可能な各プロパティの説明は、「[GitHub Actions アクション YAML](github-action-ref.md)」に記載されています。キュレートされた GitHub Action で使用できる設定オプションについては、該当するドキュメントを参照してください。 1. (オプション) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # GitHub 出力パラメータをエクスポートする CodeCatalyst ワークフローで [GitHub 出力パラメータ](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter)を使用できます。 **注記** *出力パラメータ*の別の呼び方は*変数*です。GitHub はドキュメントで*出力パラメータ*という用語を使用しているため、ここでもこの用語を使用します。以下の手順に従って GitHub 出力パラメータを GitHub Action からエクスポートし、他の CodeCatalyst ワークフローアクションで使用できるようにします。 **GitHub 出力パラメータをエクスポートするには** 1. ワークフローを開き、**[編集]** を選択します。詳細については、「[ワークフローの作成](workflows-create-workflow.md)」を参照してください。 1. エクスポートする出力パラメータを生成する **GitHub Actions** アクションで、次のような `Variables` プロパティを下位に持つ `Outputs` セクションを追加します。 ``` Actions: MyGitHubAction: Identifier: aws/github-actions-runner@v1 Outputs: Variables: - 'step-id_output-name' ``` 置換: + *step-id* を GitHub Action の `steps` セクションの `id:` プロパティの値で置き換えます。 + *output-name* を GitHub 出力パラメータの名前で置き換えます。 **例** 次の例は、`SELECTEDCOLOR` という GitHub 出力パラメータをエクスポートする方法を示しています。 ``` Actions: MyGitHubAction: Identifier: aws/github-actions-runner@v1 Outputs: Variables: - 'random-color-generator_SELECTEDCOLOR' Configuration: Steps: - name: Set selected color run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT id: random-color-generator ``` # GitHub 出力パラメータを参照する GitHub 出力パラメータを参照する手順は次のとおりです。 **GitHub 出力パラメータを参照するには** 1. 「[GitHub 出力パラメータをエクスポートする](integrations-github-action-export.md)」のステップを完了します。 GitHub 出力パラメータが他のアクションで使用できるようになりました。 1. 出力パラメータの `Variables` の値に注意してください。アンダースコア (\$1) が含まれています。 1. 次の構文を使用して出力パラメータを参照します。 ``` ${action-name.output-name} ``` 置き換え前: + *action-name* は、出力パラメータを生成する CodeCatalyst **GitHub Action** の名前で置き換えます (GitHub アクションの `name` または `id` は使用しないでください)。 + *output-name* は、前にメモした出力パラメータの `Variables` の値で置き換えます。 **例** ``` BuildActionB: Identifier: aws/build@v1 Configuration: Steps: - Run: echo ${MyGitHubAction.random-color-generator_SELECTEDCOLOR} ``` **コンテキストを含む例** 次の例は、`GitHubActionA` で `SELECTEDCOLOR` 変数を設定して出力し、`BuildActionB` で参照する方法を示しています。 ``` Actions: GitHubActionA: Identifier: aws/github-actions-runner@v1 Configuration: Steps: - name: Set selected color run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT id: random-color-generator Outputs: Variables: - 'random-color-generator_SELECTEDCOLOR' BuildActionB: Identifier: aws/build@v1 Configuration: Steps: - Run: echo ${GitHubActionA.random-color-generator_SELECTEDCOLOR} ``` # GitHub Actions アクション YAML 以下は、**GitHub Actions** アクションの YAML 定義です。このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。次のコード内で YAML プロパティを選択すると、説明が表示されます。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティと共に一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. action-name: Identifier: aws/github-actions-runner@v1 DependsOn: - dependent-action-name-1 Compute: Fleet: fleet-name Timeout: timeout-minutes Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Inputs: Sources: - source-name-1 - source-name-2 Artifacts: - artifact-name Variables: - Name: variable-name-1 Value: variable-value-1 - Name: variable-name-2 Value: variable-value-2 Outputs: Artifacts: - Name: output-artifact-1 Files: - github-output/artifact-1.jar - "github-output/build*" - Name: output-artifact-2 Files: - github-output/artifact-2.1.jar - github-output/artifact-2.2.jar Variables: - variable-name-1 - variable-name-2 AutoDiscoverReports: Enabled: true | false ReportNamePrefix: AutoDiscovered IncludePaths: - "**/*" ExcludePaths: - node_modules/cdk/junit.xml SuccessCriteria: PassRate: percent LineCoverage: percent BranchCoverage: percent Vulnerabilities: Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL Number: whole-number Reports: report-name-1: Format: format IncludePaths: - "*.xml" ExcludePaths: - report2.xml - report3.xml SuccessCriteria: PassRate: percent LineCoverage: percent BranchCoverage: percent Vulnerabilities: Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL Number: whole-number Configuration Steps: - github-actions-code ``` ## action-name (必須) アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名で特殊文字やスペースを有効にすることはできません。対応する UI: [設定] タブ/*[action-name]* ## Identifier (*action-name*/**Identifier**) アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。 **GitHub Actions** アクションには `aws/github-actions-runner@v1` を使用します。対応する UI: ワークフロー図/*action-name*/**aws/github-actions-runner@v1** ラベル ## DependsOn (*action-name*/**DependsOn**) (オプション) このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。対応する UI: [入力] タブ/**[依存 - オプション]** ## Compute (*action-name*/**Compute**) (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。対応する UI: *なし* ## Fleet (*action-name*/Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。対応する UI: [設定] タブ/**[コンピューティングフリート - オプション]** ## Timeout (*action-name*/**Timeout**) (オプション) CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。対応する UI: [設定] タブ/**[タイムアウト - オプション]** ## Environment (*action-name*/**Environment**) (オプション) アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウントおよびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用してに接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。 **注記** デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。環境タグ付けの詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: [設定] タブ/**[環境]** ## Name (*action-name*/Environment/**Name**) ([Environment](#github.environment) が含まれている場合は必須) アクションに関連付ける既存の環境の名前を指定します。対応する UI: [設定] タブ/**[環境]** ## Connections (*action-name*/Environment/**Connections**) (オプション) アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。アカウント接続を指定しない場合: + アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 + デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** ## Name (*action-name*/Environment/Connections/**Name**) ([Connections](#github.environment.connections) が含まれている場合は必須) アカウント接続の名前を指定します。対応する UI: [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** ## Role (*action-name*/Environment/Connections/**Role**) ([Connections](#github.environment.connections) が含まれている場合は必須) Amazon S3 や Amazon ECR などの AWS のサービスにアクセスして操作するために、このアクションが使用する IAM ロールの名前を指定します。このロールがスペースの AWS アカウント接続に追加されていることを確認します。アカウント接続に IAM ロールを追加するには、「[IAM ロールをアカウント接続に追加する](ipa-connect-account-addroles.md)」を参照してください。 IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーが設定されていることを確認してください。 **注記** このアクションでは、`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。 **警告** アクセス許可は、**GitHub Action** アクションに必要なアクセス許可に制限します。範囲の広いアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。対応する UI: [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** ## Inputs (*action-name*/**Inputs**) (オプション) `Inputs` セクションは、ワークフローの実行中にアクションに必要なデータを定義します。 **注記** **GitHub Actions** アクションごとに最大 4 つの入力 (1 つのソースと 3 つのアーティファクト) が許可されます。変数はこの合計にはカウントされません。異なる入力 (ソースとアーティファクトなど) にあるファイルを参照する必要がある場合、ソース入力はプライマリ入力で、アーティファクトはセカンダリ入力になります。セカンダリ入力内のファイルへの参照には、プライマリからファイルを区別するための特別なプレフィックスが付きます。詳細については、「[例: 複数のアーティファクトでのファイルの参照](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file)」を参照してください。対応する UI: **[入力] タブ** ## Sources (*action-name*/Inputs/**Sources**) (オプション) アクションに必要なソースリポジトリを表すラベルを指定します。現在、サポートされているラベルは `WorkflowSource` のみです。これは、ワークフロー定義ファイルが保存されているソースリポジトリを表します。ソースを省略する場合は、`action-name/Inputs/Artifacts` で少なくとも 1 つの入力アーティファクトを指定する必要があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。対応する UI: [入力] タブ/**[ソース - オプション]** ## Artifacts - input (*action-name*/Inputs/**Artifacts**) (オプション) このアクションへの入力として提供する以前のアクションのアーティファクトを指定します。これらのアーティファクトは、前のアクションで出力アーティファクトとして既に定義されている必要があります。入力アーティファクトを指定しない場合は、`action-name/Inputs/Sources` で少なくとも 1 つのソースリポジトリを指定する必要があります。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **注記** **[アーティファクト - オプション]** のドロップダウンリストが使用できない場合 (ビジュアルエディタ)、または YAML の検証時にエラーが発生する場合 (YAML エディタ)、アクションが 1 つの入力のみをサポートしていることが原因である可能性があります。この場合はソース入力を削除してみてください。対応する UI: [入力] タブ/**[アーティファクト - オプション]** ## Variables - input (*action-name*/Inputs/**Variables**) (オプション) アクションで使用できるようにしたい入力変数を定義する名前と値のペアのシーケンスを指定します。変数名に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、変数名で特殊文字とスペースを有効にすることはできません。変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。対応する UI: [入力] タブ/**[変数 - オプション]** ## Outputs (*action-name*/**Outputs**) (オプション) ワークフローの実行中にアクションによって出力されるデータを定義します。対応する UI: **[出力]** タブ ## Artifacts - output (*action-name*/Outputs/**Artifacts**) (オプション) アクションによって生成されるアーティファクトの名前を指定します。アーティファクト名はワークフロー内で一意でなければならず、英数字 (a～z、A～Z、0～9) とアンダースコア (\$1) しか使用できません。スペース、ハイフン (-)、その他の特殊文字は使用できません。引用符を使用して、出力アーティファクト名でスペース、ハイフン、その他の特殊文字を有効にすることはできません。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [出力] タブ/**[アーティファクト]** ## Name (*action-name*/Outputs/Artifacts/**Name**) ([Artifacts - output](#github.outputs.artifacts) が含まれている場合は必須) アクションによって生成されるアーティファクトの名前を指定します。アーティファクト名はワークフロー内で一意でなければならず、英数字 (a～z、A～Z、0～9) とアンダースコア (\$1) しか使用できません。スペース、ハイフン (-)、その他の特殊文字は使用できません。引用符を使用して、出力アーティファクト名でスペース、ハイフン、その他の特殊文字を有効にすることはできません。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドアーティファクト名]** ## Files (*action-name*/Outputs/Artifacts/**Files**) ([Artifacts - output](#github.outputs.artifacts) が含まれている場合は必須) CodeCatalyst がアクションによって出力されるアーティファクトに含めるファイルを指定します。これらのファイルは、実行時にワークフローアクションによって生成され、ソースリポジトリでも使用できます。ファイルパスは、ソースリポジトリまたは前のアクションからのアーティファクトに設定でき、ソースリポジトリまたはアーティファクトルートを基準とすることができます。glob パターンを使用してパスを指定できます。例: + ビルドまたはソースリポジトリの場所のルートにある 1 つのファイルを指定するには、`my-file.jar` を使用します。 + サブディレクトリ内の 1 つのファイルを指定するには、`directory/my-file.jar` または `directory/subdirectory/my-file.jar` を使用します。 + すべてのファイルを指定するには、`"**/*"` を使用します。glob パターン `**` は、任意の数のサブディレクトリにマッチすることを示します。 + `directory` という名前のディレクトリ内のすべてのファイルとディレクトリを指定するには、`"directory/**/*"` を使用します。glob パターン `**` は、任意の数のサブディレクトリにマッチすることを示します。 + `directory` という名前のディレクトリ内のすべてのファイルを指定するが、そのサブディレクトリを含めないようにするには、`"directory/*"` を使用します。 **注記** ファイルパスに 1 つ以上のアスタリスク (`*`) またはその他の特殊文字が含まれている場合は、パスを二重引用符 (`""`) で囲みます。特殊文字の詳細については、「[構文ガイドラインと規則](workflow-reference.md#workflow.terms.syntax.conv)」を参照してください。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 **注記** 場合によっては、ファイルパスにプレフィックスを追加して、どのアーティファクトまたはソースにあるのかを示す必要があります。詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」および「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。対応する UI: [出力] タブ/[アーティファクト]/[アーティファクトを追加]/**[ビルドで生成されるファイル]** ## Variables - output (*action-name*/Outputs/**Variables**) (オプション) 後続のアクションで使用できるように、アクションがエクスポートする変数を指定します。変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。対応する UI: [出力] タブ/[変数]/**[変数を追加]** ## variable-name-1 (*action-name*/Outputs/Variables**variable-name-1**) (オプション) アクションでエクスポートする変数の名前を指定します。この変数は、同じアクションの `Inputs` セクションか `Steps` セクションであらかじめ定義されている必要があります。変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。対応する UI: [出力] タブ/[変数]/[変数を追加]/**[名前]** ## AutoDiscoverReports (*action-name*/Outputs/**AutoDiscoverReports**) (オプション) 自動検出機能の設定を定義します。自動検出を有効にすると、CodeCatalyst はアクションに渡されたすべての `Inputs` と、アクション自体によって生成されたすべてのファイルを検索し、テストレポート、コードカバレッジレポート、ソフトウェアコンポジション分析 (SCA) レポートを探します。検出された各レポートは、CodeCatalyst レポートに変換されます。*CodeCatalyst レポート*は、CodeCatalyst サービスに完全に統合されており、CodeCatalyst コンソールを介して表示および操作できます。 **注記** デフォルトでは、自動検出機能はすべてのファイルを検査します。[IncludePaths](#github.reports.includepaths) または [ExcludePaths](#github.reports.excludepaths) プロパティを使用して、検査するファイルを制限できます。対応する UI: *なし* ## Enabled (*action-name*/Outputs/AutoDiscoverReports/**Enabled**) (オプション) 自動検出機能を有効または無効にします。有効な値は `true` または `false` です。 `Enabled` を省略した場合、デフォルトは `true` です。対応する UI: [出力] タブ/[レポート]/**[レポートを自動的に検出]** ## ReportNamePrefix (*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**) ([AutoDiscoverReports](#github.outputs.autodiscover) が含まれ、有効になっている場合は必須) 関連する CodeCatalyst レポートに名前を付けるために、CodeCatalyst が検出したすべてのレポートに付加するプレフィックスを指定します。例えば、プレフィックスを `AutoDiscovered` に指定し、CodeCatalyst が 2 つのテストレポート、`TestSuiteOne.xml`、`TestSuiteTwo.xml` を自動的に検出する場合、関連する CodeCatalyst レポートには `AutoDiscoveredTestSuiteOne` と `AutoDiscoveredTestSuiteTwo` という名前が付けられます。対応する UI: [出力] タブ/[レポート]/[レポートを自動的に検出]/**[レポートのプレフィックス]** ## IncludePaths (*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**) または (*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**) ([AutoDiscoverReports](#github.outputs.autodiscover) が含まれ、有効になっている場合、または [Reports](#github.configuration.reports) が含まれている場合は必須) CodeCatalyst が未加工レポートを検索するときに含めるファイルとファイルパスを指定します。例えば、`"/test/report/*"` を指定すると、CodeCatalyst は `/test/report/*` ディレクトリを検索するアクションで使用される[ビルドイメージ](build-images.md)全体を検索します。そのディレクトリが見つかると、CodeCatalyst はそのディレクトリ内のレポートを検索します。 **注記** ファイルパスに 1 つ以上のアスタリスク (`*`) またはその他の特殊文字が含まれている場合は、パスを二重引用符 (`""`) で囲みます。特殊文字の詳細については、「[構文ガイドラインと規則](workflow-reference.md#workflow.terms.syntax.conv)」を参照してください。このプロパティを省略した場合、デフォルトは `"**/*"` です。つまり、検索にはすべてのパスのすべてのファイルが含まれます。 **注記** 手動で設定するレポートの場合、`IncludePaths` は単一のファイルに一致する glob パターンである必要があります。対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[パスを含める/除外する]/**[パスを含める]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[パスを含める/除外する]/**[パスを含める]** ## ExcludePaths (*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**) または (*action-name*/Outputs/Reports/*report-name-1*/**ExcludePaths**) (オプション) 未加工レポートを検索するときに CodeCatalyst が除外するファイルとファイルパスを指定します。例えば、`"/test/my-reports/**/*"` を指定した場合、CodeCatalyst は `/test/my-reports/` ディレクトリ内のファイルを検索しません。ディレクトリ内のすべてのファイルを無視するには、`**/*` glob パターンを使用します。 **注記** ファイルパスに 1 つ以上のアスタリスク (`*`) またはその他の特殊文字が含まれている場合は、パスを二重引用符 (`""`) で囲みます。特殊文字の詳細については、「[構文ガイドラインと規則](workflow-reference.md#workflow.terms.syntax.conv)」を参照してください。対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[パスを含める/除外する]/**[パスを除外する]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[パスを含める/除外する]/**[パスを除外する]** ## SuccessCriteria (*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**) または (*action-name*/Outputs/Reports/*report-name-1*/**SuccessCriteria**) (オプション) テストレポート、コードカバレッジレポート、ソフトウェアコンポジション分析 (SCA) レポート、静的分析 (SA) レポートの成功基準を指定します。詳細については、「[レポートの成功基準の設定](test-config-action.md#test.success-criteria)」を参照してください。対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/**[成功基準]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/**[成功基準]** ## PassRate (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、テストレポート内のテストに求められる合格の割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。パスレートの基準は、テストレポートにのみ適用されます。テストレポートの詳細については、「[テストレポート](test-workflow-actions.md#test-reports)」を参照してください。対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[成功基準]/**[パスレート]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[成功基準]/**[パスレート]** ## LineCoverage (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、コードカバレッジレポート内でカバーする必要がある行の割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。ラインカバレッジ基準は、コードカバレッジレポートにのみ適用されます。コードカバレッジレポートの詳細については、「[コードカバレッジレポート](test-workflow-actions.md#test-code-coverage-reports)」を参照してください。対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[成功基準]/**[ラインカバレッジ]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[成功基準]/**[ラインカバレッジ]** ## BranchCoverage (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、コードカバレッジレポート内でカバーする必要があるブランチの割合を指定します。有効な値には 10 進数が含まれます。例: `50`、`60.5`。ブランチカバレッジ基準は、コードカバレッジレポートにのみ適用されます。コードカバレッジレポートの詳細については、「[コードカバレッジレポート](test-workflow-actions.md#test-code-coverage-reports)」を参照してください。対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[成功基準]/**[ブランチカバレッジ]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[成功基準]/**[ブランチカバレッジ]** ## Vulnerabilities (*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**) または (*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**) (オプション) 関連する CodeCatalyst レポートが合格としてマークされるために、SCA レポートで許容される脆弱性の数と重要度の上限を指定します。脆弱性を指定するには、以下を指定する必要があります。 + カウントに含める脆弱性の最小重要度。有効な値は、重要度が高い順に `CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`INFORMATIONAL` です。例えば、`HIGH` を選択すると、`HIGH` と `CRITICAL` の脆弱性が集計されます。 + 指定された重要度の脆弱性の最大許容数。この数を超えると、CodeCatalyst レポートは不合格としてマークされます。有効な値は整数です。脆弱性の基準は SCA レポートにのみ適用されます。SCA レポートの詳細については、「[ソフトウェア構成分析レポート](test-workflow-actions.md#test-sca-reports)」を参照してください。最小重要度を指定するには、`Severity` プロパティを使用します。脆弱性の最大数を指定するには、`Number` プロパティを使用します。 SCA レポートの詳細については、「[品質レポートのタイプ](test-workflow-actions.md#test-reporting)」を参照してください。対応する UI: + [出力] タブ/[レポート]/[レポートを自動的に検出]/[成功基準]/**[脆弱性]** + [出力] タブ/[レポート]/[レポートを手動で設定]/*report-name-1*/[成功基準]/**[脆弱性]** ## Reports (*action-name*/Outputs/**Reports** ) (オプション) テストレポートの設定を指定するセクション。対応する UI: [出力] タブ/**[レポート]** ## report-name-1 (*action-name*/Outputs/Reports/**report-name-1**) ([Reports](#github.configuration.reports) が含まれている場合は必須) 未加工レポートから生成される CodeCatalyst レポートに付ける名前。対応する UI: [出力] タブ/[レポート]/[レポートを手動で設定]/**[レポート名]** ## Format (*action-name*/Outputs/Reports/*report-name-1*/**Format**) ([Reports](#github.configuration.reports) が含まれている場合は必須) レポートに使用するファイル形式を指定します。指定できる値は以下のとおりです。 + テストレポートの場合: + Cucumber JSON には、**[Cucumber ]** (ビジュアルエディタ) または [`CUCUMBERJSON`] (YAML エディタ) を指定します。 + JUnit XML の場合は、**[JUnit]** (ビジュアルエディタ) または [`JUNITXML`] (YAML エディタ) を指定します。 + NUnit XML の場合は、**[NUnit]** (ビジュアルエディタ) または [`NUNITXML`] (YAML エディタ) を指定します。 + NUnit 3 XML の場合は、**[NUnit3]** (ビジュアルエディタ) または [`NUNIT3XML`] (YAML エディタ) を指定します。 + Visual Studio TRX の場合は、**[Visual Studio TRX]** (ビジュアルエディタ) または [`VISUALSTUDIOTRX`] (YAML エディタ) を指定します。 + TestNG XML の場合は、**[TestNG]** (ビジュアルエディタ) または [`TESTNGXML`] (YAML エディタ) を指定します。 + コードカバレッジレポートの場合: + Clover XML の場合は、**[Clover]** (ビジュアルエディタ) または [`CLOVERXML`] (YAML エディタ) を指定します。 + Cobertura XML の場合は、**[Cobertura]** (ビジュアルエディタ) または [`COBERTURAXML`] (YAML エディタ) を指定します。 + JaCoCo XML の場合は、**[JaCoCo]** (ビジュアルエディタ) または [`JACOCOXML`] (YAML エディタ) を指定します。 + [[simplecov-json]](https://github.com/simplecov-ruby/simplecov) ではなく [[simplecov]](https://github.com/vicentllongo/simplecov-json) によって生成された SimpleCov JSON の場合は、**[Simplecov]** (ビジュアルエディタ) または [`SIMPLECOV`] (YAML エディタ) を指定します。 + ソフトウェアコンポジション分析 (SCA) レポートの場合: + SARIF の場合は、**[SARIF]** (ビジュアルエディタ) または [`SARIFSCA`] (YAML エディタ) を指定します。対応する UI: [出力] タブ/[レポート]/[レポートを手動で設定]/[レポートを追加]/*report-name-1*/**[レポートタイプ]** および **[レポート形式]** ## Configuration (*action-name*/**Configuration**) (必須) アクションの設定プロパティを定義できるセクション。対応する UI: **[設定]** タブ ## Steps (*action-name*/Configuration/**Steps**) (必須) GitHub Action コードを、[GitHub Marketplace](https://github.com/marketplace) のアクションの詳細ページに表示されるとおりに指定します。次のガイドラインに従ってコードを追加します。 1. GitHub Action の `steps:` セクションのコードを CodeCatalyst ワークフローの `Steps:` セクションに貼り付けます。コードはダッシュ (-) で始まり、次のような形式になります。貼り付ける GitHub コード: ``` - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: false DEFAULT_BRANCH: master GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` 1. 貼り付けたコードをレビューし、CodeCatalyst の規格に準拠するように必要に応じて変更します。例えば、前述のコードブロックでは、*赤い斜体*のコードを削除し、**太字**のコードを追加することができます。 CodeCatalyst ワークフロー yaml: ``` Steps: - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: false DEFAULT_BRANCH: mastermain GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` 1. GitHub Action に含まれているが、`steps:` セクション内に存在しない追加のコードについては、CodeCatalyst の対応するコードを使用して CodeCatalyst ワークフローに追加します。GitHub コードを CodeCatalyst に移植する方法については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。詳細な移行手順は、このガイドの範囲外です。 **GitHub Actions** アクションでファイルパスを指定する方法の例を次に示します。 ``` Steps: - name: Lint Code Base uses: github/super-linter@v4 ... - run: cd /sources/WorkflowSource/MyFolder/ && cat file.txt - run: cd /artifacts/MyGitHubAction/MyArtifact/MyFolder/ && cat file2.txt ``` 出力ファイル名とパスの詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」と「[アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md)」を参照してください。対応する UI: [設定] タブ/**[GitHub Actions YAML]** # コンピューティングイメージとランタイムイメージの構成 CodeCatalyst ワークフローでは、CodeCatalyst でワークフローアクションの実行に使用するコンピューティングとランタイム環境イメージを指定できます。 *コンピューティング*とは、CodeCatalyst がワークフローアクションを実行するために管理および保守するコンピューティングエンジン (CPU、メモリ、およびオペレーティングシステム) を指します。 **注記** コンピューティングがワークフローのプロパティとして定義されている場合、そのワークフロー内のアクションのプロパティとしてコンピューティングを定義することはできません。同様に、コンピューティングがアクションのプロパティとして定義されている場合、ワークフロー内でコンピューティングを定義することはできません。 *ランタイム環境イメージ*は、CodeCatalyst がワークフローアクションを実行する Docker コンテナです。Docker コンテナは、選択したコンピューティングプラットフォーム上で実行され、オペレーティングシステムと、、Node.js AWS CLI、.tar などのワークフローアクションに必要な追加のツールが含まれています。 **Topics** + [ ## コンピューティングタイプ ](#compute.types) + [ ## コンピューティングフリート ](#compute.fleets) + [ ## オンデマンドフリートのプロパティ ](#compute.on-demand) + [ ## プロビジョニングされたフリートのプロパティ ](#compute.provisioned-fleets) + [ # プロビジョニングされたフリートの作成 ](projects-create-compute-resource.md) + [ # プロビジョニングされたフリートの編集 ](edit-compute-resource.md) + [ # プロビジョニングされたフリートの削除 ](delete-compute-resource.md) + [ # アクションへのフリートまたはコンピューティングの割り当て ](workflows-assign-compute-resource.md) + [ # アクション間でのコンピューティングの共有する ](compute-sharing.md) + [ # ランタイム環境イメージの指定 ](build-images.md) ## コンピューティングタイプ CodeCatalyst には次のコンピューティングタイプが用意されています。 + Amazon EC2 + AWS Lambda Amazon EC2 はアクションの実行中に最適化された柔軟性を提供し、Lambda はアクションの起動速度を最適化します。Lambda では、起動レイテンシーが低いため、ワークフローアクションの実行速度が速くなります。Lambda では、一般的なランタイムでサーバーレスアプリケーションを構築、テスト、デプロイできる基本的なワークフローを実行できます。これらのランタイムには、Node.js、Python、Java、.NET、Go が含まれます。ただし、Lambda でサポートされていないユースケースもいくつかあります。それによって影響がある場合は Amazon EC2 コンピューティングタイプを使用してください。 + Lambda では、指定されたレジストリからのランタイム環境イメージをサポートしていません。 + Lambda では、root 権限を必要とするツールをサポートしていません。`yum` や `rpm` などのツールには、Amazon EC2 コンピューティングタイプや root 権限を必要としないその他のツールを使用してください。 + Lambda では Docker のビルドや実行をサポートしていません。Docker イメージを使用する以下のアクションはサポートされていません。スタックのデプロイ AWS CloudFormation 、Amazon ECS へのデプロイ、Amazon S3 パブリッシュ、 AWS CDK ブートストラップ、 AWS CDK デプロイ、 AWS Lambda 呼び出し、GitHub Actions。CodeCatalyst GitHub Actions アクション内で実行されている Docker ベースの GitHub Actions も、Lambda コンピューティングではサポートされていません。Podman など、root 権限を必要としない代替手段を使用できます。 + Lambda では、`/tmp` 外部のファイルへの書き込みがサポートされていません。ワークフローアクションを構成するときは、ツールを再構成して `/tmp` にインストールまたは書き込みできます。`npm` をインストールするビルドアクションがある場合は、必ず `/tmp` にインストールするように構成してください。 + Lambda では 15 分を超えるランタイムをサポートしていません。 ## コンピューティングフリート CodeCatalyst では、次のコンピューティングフリートが用意されています。 + オンデマンドフリート + プロビジョニングされたフリートオンデマンドフリートでは、ワークフローアクションが開始されると、ワークフローが必要なリソースをプロビジョニングします。マシンはアクションが終了すると破棄されます。アクションを実行している間のみ、分単位で料金が発生します。オンデマンドフリートはフルマネージド型で、需要の急増にも対応できる自動スケーリング機能を備えています。 CodeCatalyst には、CodeCatalyst によって維持される Amazon EC2 を搭載したマシンを含むプロビジョニングされたフリートも用意されています。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを構成します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートでは、マシンは常に稼働しており、プロビジョニングされている間はコストが発生します。フリートを作成、更新、または削除するには、**スペース管理者**ロールまたは**プロジェクト管理者**ロールが必要です。 ## オンデマンドフリートのプロパティ CodeCatalyst には以下のオンデマンドフリートがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/workflows-working-compute.html) **注記** オンデマンドフリートの仕様は請求階層によって異なります。詳細については、「[料金](https://codecatalyst.aws/explore/pricing)」を参照してください。フリートが選択されていない場合、CodeCatalyst では `Linux.x86-64.Large` を使用します。 ## プロビジョニングされたフリートのプロパティプロビジョニングされたフリートには次のプロパティがあります。 **オペレーティングシステム** オペレーティングシステム。使用できるオペレーションシステムは次のとおりです。 + Amazon Linux 2 + Windows Server 2022 **注記** Windows フリートはビルドアクションでのみサポートされています。その他のアクションでは現在 Windows をサポートしていません。 **アーキテクチャ** プロセッサアーキテクチャ。以下のアーキテクチャが利用可能です。 + x86\$164 + Arm64 **マシンタイプ** 各インスタンスのマシンタイプ。次のマシンタイプを使用できます｡ [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/workflows-working-compute.html) **Capacity** フリートに割り当てられるマシンの初期数。これにより、並列で実行できるアクションの数が定義されます。 **スケーリングモード** アクション数がフリート容量を超えたときの動作を定義します。 **オンデマンドで追加の容量をプロビジョニングする** オンデマンドで追加のマシンを設定すると、新しいアクションの実行に応じて自動的にスケールアップし、アクションが完了するとベース容量までスケールダウンします。実行中のマシンごとに分単位でのお支払いとなるため、追加のコストが発生する可能性があります。 **追加のフリート容量が利用可能になるまで待機する** アクションの実行は、マシンが使用可能になるまでキューに入れられます。これにより、さらにマシンが割り当てられないため、追加のコストが抑えられます。 # プロビジョニングされたフリートの作成以下の手順に従って、プロビジョニングされたフリートを作成します。 **注記** プロビジョニングされたフリートは、アイドル状態が 2 週間続くと、非アクティブ化されます。再度使用すると、自動的に再アクティブ化されますが、この再アクティブ化によりレイテンシーが発生する可能性があります。 **プロビジョニングされたフリートを作成するには** 1. ナビゲーションペインで **[CI/CD]**、**[コンピューティング]** の順に選択します。 1. **[プロビジョニングされたフリートの作成]** を選択します。 1. **[プロビジョニングされたフリート名]** テキストフィールドに、フリートの名前を入力します。 1. **[オペレーティングシステム]** ドロップダウンメニューから、オペレーティングシステムを選択します。 1. **[マシンタイプ]** ドロップダウンメニューから、マシンのマシンタイプを選択します。 1. **[キャパシティ]** テキストフィールドに、フリートのマシンの最大数を入力します。 1. **[スケーリングモード]** ドロップダウンメニューから、目的のオーバーフロー動作を選択します。フィールドの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 1. **[作成]** を選択します。プロビジョニングされたフリートを作成したら、アクションに割り当てる準備ができました。詳細については、「[アクションへのフリートまたはコンピューティングの割り当て](workflows-assign-compute-resource.md)」を参照してください。 # プロビジョニングされたフリートの編集以下の手順に従って、プロビジョニングされたフリートを編集します。 **注記** プロビジョニングされたフリートは、アイドル状態が 2 週間続くと、非アクティブ化されます。再度使用すると、自動的に再アクティブ化されますが、この再アクティブ化によりレイテンシーが発生する可能性があります。 **プロビジョニングされたフリートを編集するには** 1. ナビゲーションペインで **[CI/CD]**、**[コンピューティング]** の順に選択します。 1. **[プロビジョニングされたフリート]** 一覧で、編集するフリートを選択します。 1. **[編集]** を選択します。 1. **[キャパシティ]** テキストフィールドに、フリートのマシンの最大数を入力します。 1. **[スケーリングモード]** ドロップダウンメニューから、目的のオーバーフロー動作を選択します。フィールドの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 1. **[保存]** を選択します。 # プロビジョニングされたフリートの削除プロビジョニングされたフリートを削除するには、以下の手順に従います。 **プロビジョニングされたフリートを削除するには** **警告** プロビジョニングされたフリートを削除する前に、アクションの YAML コードから `Fleet` プロパティを削除して、すべてのアクションから削除します。削除後もプロビジョニングされたフリートを参照し続けるアクションは、次回アクションが実行されたときに失敗します。 1. ナビゲーションペインで **[CI/CD]**、**[コンピューティング]** の順に選択します。 1. **[プロビジョニングされたフリート]** 一覧で、削除するフリートを選択します。 1. **[削除]** を選択します。 1. **delete** と入力して削除を確定します。 1. **[削除]** を選択します。 # アクションへのフリートまたはコンピューティングの割り当てデフォルトでは、ワークフローアクションでは Amazon EC2 コンピューティングタイプの `Linux.x86-64.Large` オンデマンドフリートを使用します。代わりにプロビジョニングされたフリートを使用するか、`Linux.x86-64.2XLarge` などの異なるオンデマンドフリートを使用するには、次の手順に従います。 ------ #### [ Visual ] **[開始する前に]** + プロビジョニングされたフリートを割り当てる場合は、まずプロビジョニングされたフリートを作成する必要があります。詳細については、「[プロビジョニングされたフリートの作成](projects-create-compute-resource.md)」を参照してください。 **プロビジョニングされたフリートまたは異なるフリートタイプをアクションに割り当てるには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、プロビジョニングされたフリートまたは新しいフリートタイプを割り当てるアクションを選択します。 1. **[設定]** タブを選択します。 1. **[コンピューティングフリート]** で以下を実行します。ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **[開始する前に]** + プロビジョニングされたフリートを割り当てる場合は、まずプロビジョニングされたフリートを作成する必要があります。詳細については、「[プロビジョニングされたフリートの作成](projects-create-compute-resource.md)」を参照してください。 **プロビジョニングされたフリートまたは異なるフリートタイプをアクションに割り当てるには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. プロビジョニングされたフリートまたは新しいフリートタイプを割り当てるアクションを見つけます。 1. アクションで `Compute` プロパティを追加し、`Fleet` をフリートの名前またはオンデマンドフリートタイプに設定します。詳細については、アクションの「[ビルドおよびテストアクション YAML](build-action-ref.md)」の `Fleet` プロパティの説明を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # アクション間でのコンピューティングの共有するデフォルトでは、ワークフロー内のアクションは [[フリート]](workflows-working-compute.md#compute.fleets) 内の個別のインスタンスで実行されます。この動作では、入力の状態を分離し、予測可能なアクションを実行できます。デフォルトの動作では、ファイルや変数などのコンテキストをアクション間で共有するための明示的な設定が必要です。コンピューティング共有は、同じインスタンスでワークフロー内のすべてのアクションを実行できる機能です。コンピューティング共有を使用すると、インスタンスのプロビジョニングに費やす時間が短縮されるため、ワークフローの実行時間が短縮されます。ワークフロー設定を追加することなく、アクション間でファイル (アーティファクト) を共有することもできます。ワークフローがコンピューティング共有を使用して実行されると、デフォルトまたは指定されたフリートのインスタンスは、そのワークフロー内のすべてのアクションの期間中予約されます。ワークフローの実行が完了すると、インスタンス予約が解放されます。 **Topics** + [ ## 共有コンピューティングでの複数のアクションの実行 ](#how-to-compute-share) + [ ## コンピューティング共有に関する考慮事項 ](#compare-compute-sharing) + [ ## コンピューティング共有の有効化 ](#compute-sharing-steps) + [ ## 例 ](#compute-sharing-examples) ## 共有コンピューティングでの複数のアクションの実行ワークフローレベルで定義 YAML の `Compute` 属性を使用して、アクションのフリート共有プロパティとコンピューティング共有プロパティの両方を指定できます。CodeCatalyst のビジュアルエディタを使用してコンピューティングプロパティを設定することもできます。フリートを指定するには、既存のフリートの名前を設定し、コンピューティングタイプを **[EC2]** に設定し、コンピューティング共有をオンにします。 **注記** コンピューティング共有は、コンピューティングタイプが **[EC2]** に設定されている場合のみサポートされ、Windows Server 2022 オペレーティングシステムではサポートされていません。コンピューティングフリート、コンピューティングタイプ、プロパティの詳細については、「[コンピューティングイメージとランタイムイメージの構成](workflows-working-compute.md)」を参照してください。 **注記** 無料利用枠にいて、ワークフロー定義 YAML で `Linux.x86-64.XLarge` または `Linux.x86-64.2XLarge` フリートを手動で指定すると、アクションは引き続きデフォルトのフリート (`Linux.x86-64.Large`) で実行されます。コンピューティングの可用性と料金の詳細については、「[階層オプションの表](https://codecatalyst.aws/explore/pricing)」を参照してください。コンピューティング共有を有効にすると、ワークフローソースを含むフォルダがアクション間で自動的にコピーされます。ワークフロー定義 (YAML ファイル) 全体で出力アーティファクトを設定し、入力アーティファクトとして参照する必要はありません。ワークフロー作成者は、コンピューティング共有を使用しない場合と同様に、入力と出力を使用して環境変数をワイヤアップする必要があります。ワークフローソース外のアクション間でフォルダを共有する場合は、ファイルキャッシュを検討してください。詳細については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」および「[ワークフロー実行間のファイルのキャッシュ](workflows-caching.md)」を参照してください。ワークフロー定義ファイルが存在するソースリポジトリは、ラベル「`WorkflowSource`」によって識別されます。コンピューティング共有を使用している間、ワークフローソースは、それを参照する最初のアクションでダウンロードされ、ワークフロー実行のその後のアクションで自動的に使用可能になります。ファイルの追加、変更、削除など、アクションによってワークフローソースを含むフォルダに加えられた変更は、ワークフロー内の後続のアクションにも表示されます。コンピューティング共有を使用せずに、任意のワークフローアクションのワークフローソースフォルダにあるファイルを参照できます。詳細については、「[ソースリポジトリファイルの参照](workflows-sources-reference-files.md)」を参照してください。 **注記** コンピューティング共有ワークフローでは、並列アクションを設定できないように、アクションの厳密なシーケンスを指定する必要があります。出力アーティファクトはシーケンス内の任意のアクションで設定できますが、入力アーティファクトはサポートされていません。 ## コンピューティング共有に関する考慮事項ワークフローの実行を高速化し、同じインスタンスを使用するワークフロー内のアクション間でコンテキストを共有するために、コンピューティング共有を使用してワークフローを実行できます。コンピューティング共有の使用がシナリオに適しているかどうかを判断するには、以下を考慮してください。 | | コンピューティング共有 | コンピューティング共有なし | | --- | --- | --- | | コンピューティングタイプ | Amazon EC2 | Amazon EC2、AWS Lambda | | インスタンスのプロビジョニング | 同じインスタンスで実行されるアクション | 別のインスタンスで実行されるアクション | | オペレーティングシステム | Amazon Linux 2 | Amazon Linux 2、Windows Server 2022 (ビルドアクションのみ) | | ファイルの参照 | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` | `$CATALYST_SOURCE_DIR_WorkflowSource`, `/sources/WorkflowSource/` | | Workflow 構造 | アクションはシーケンシャルにしか実行できません | アクションは並列で実行できます | | ワークフローアクション間のデータへのアクセス | キャッシュされたワークフローソースにアクセスする (`WorkflowSource`) | 共有アーティファクトのアクセス出力 (追加の設定が必要) | ## コンピューティング共有の有効化次の手順に従って、ワークフローのコンピューティング共有を有効にします。 ------ #### [ Visual ] **ビジュアルエディタを使用してコンピューティング共有を有効にするには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. **[ワークフロー]** プロパティを選択します。 1. **[コンピューティングタイプ]** ドロップダウンメニューから **[EC2]** を選択します。 1. (オプション) **[コンピューティングフリート - オプション]** ドロップダウンメニューから、ワークフローアクションの実行に使用するフリートを選択します。オンデマンドフリートを選択するか、プロビジョニングされたフリートを作成して選択できます。詳細については、「[プロビジョニングされたフリートの作成](projects-create-compute-resource.md)」および「[アクションへのフリートまたはコンピューティングの割り当て](workflows-assign-compute-resource.md)」を参照してください。 1. トグルを切り替えてコンピューティング共有を有効にし、ワークフロー内のアクションを同じフリートで実行します。 1. (オプション) ワークフローの実行モードを選択します。詳細については、「[実行のキュー動作の構成](workflows-configure-runs.md)」を参照してください。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用してコンピューティング共有を有効にするには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. コンピューティング共有をオンにして、`SharedInstance` フィールドを `TRUE` に、`Type` を `EC2` に設定します。`Fleet` をワークフローアクションの実行に使用するコンピューティングフリートに設定します。オンデマンドフリートを選択するか、プロビジョニングされたフリートを作成して選択できます。詳細については、「[プロビジョニングされたフリートの作成](projects-create-compute-resource.md)」および「[アクションへのフリートまたはコンピューティングの割り当て](workflows-assign-compute-resource.md)」を参照してください。ワークフロー YAML で、次のようなコードを追加します。 ``` Name: MyWorkflow SchemaVersion: "1.0" Compute: # Define compute configuration. Type: EC2 Fleet: MyFleet # Optionally, choose an on-demand or provisioned fleet. SharedInstance: true # Turn on compute sharing. Default is False. Actions: BuildFirst: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: ... ... ``` 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ ## 例 **Topics** + [ ### 例: Amazon S3 Publish ](#compute-share-s3) ### 例: Amazon S3 Publish 次のワークフロー例は、Amazon S3 Publish アクションを 2 つの方法で実行する方法を示しています。まず入力アーティファクトを使用し、次にコンピューティング共有を使用します。コンピューティング共有では、キャッシュされた `WorkflowSource` にアクセスできるため、入力アーティファクトは必要ありません。さらに、ビルドアクションの出力アーティファクトが不要になりました。S3 Publish アクションは、明示的 `DependsOn` プロパティを使用してシーケンシャルアクションを維持するように設定されています。S3 Publish アクションを実行するには、ビルドアクションが正常に実行されている必要があります。 + コンピューティング共有なしでは、入力アーティファクトを使用し、出力を後続のアクションと共有する必要があります。 ``` Name: S3PublishUsingInputArtifact SchemaVersion: "1.0" Actions: Build: Identifier: aws/build@v1 Outputs: Artifacts: - Name: ArtifactToPublish Files: [output.zip] Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: ./build.sh # Build script that generates output.zip PublishToS3: Identifier: aws/s3-publish@v1 Inputs: Artifacts: - ArtifactToPublish Environment: Connections: - Role: codecatalyst-deployment-role Name: dev-deployment-role Name: dev-connection Configuration: SourcePath: output.zip DestinationBucketName: amzn-s3-demo-bucket ``` + `SharedInstance` を `TRUE` に設定してコンピューティング共有を使用する場合、同じインスタンスで複数のアクションを実行し、単一のワークフローソースを指定してアーティファクトを共有できます。入力アーティファクトは必須ではなく、指定できません。 ``` Name: S3PublishUsingComputeSharing SchemaVersion: "1.0" Compute: Type: EC2 Fleet: dev-fleet SharedInstance: TRUE Actions: Build: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: ./build.sh # Build script that generates output.zip PublishToS3: Identifier: aws/s3-publish@v1 DependsOn: - Build Environment: Connections: - Role: codecatalyst-deployment-role Name: dev-deployment-role Name: dev-connection Configuration: SourcePath: output.zip DestinationBucketName: amzn-s3-demo-bucket ``` # ランタイム環境イメージの指定 *[ランタイム環境イメージ]* は、CodeCatalyst がワークフローアクションを実行する Docker コンテナです。Docker コンテナは、選択したコンピューティングプラットフォーム上で実行され、オペレーティングシステムと、、Node.js AWS CLI、.tar などのワークフローアクションに必要な追加のツールが含まれています。デフォルトでは、ワークフローアクションは CodeCatalyst によって提供および保守されている [[アクティブなイメージ]](#build-curated-images) のいずれかで実行されます。ビルドアクションとテストアクションのみがカスタムイメージをサポートします。詳細については、「[カスタムランタイム環境の Docker イメージをアクションに割り当てる](#build-images-specify)」を参照してください。 **Topics** + [ ## アクティブなイメージ ](#build-curated-images) + [ ## アクティブなイメージに必要なツールが含まれていない場合はどうなりますか？ ](#build-images-more-tools) + [ ## カスタムランタイム環境の Docker イメージをアクションに割り当てる ](#build-images-specify) + [ ## 例 ](#workflows-working-custom-image-ex) ## アクティブなイメージ *[アクティブなイメージ]* は、CodeCatalyst によって完全にサポートされ、プリインストールされたツールを含むランタイム環境イメージです。現在、アクティブイメージには 2 つのセットがあります。1 つは 2024 年 3 月にリリースされ、もう 1 つは 2022 年 11 月にリリースされます。アクションが 2024 年 3 月または 2022 年 11 月のイメージを使用するかどうかは、アクションによって異なります。 + 2024 年 3 月 26 日以降にワークフローに追加されるビルドアクションとテストアクションには、[[2024 年 3 月のイメージ]](#build.default-image) を明示的に指定する `Container` セクションが YAML 定義に含まれます。オプションで `Container` セクションを削除して、[[2022 年 11 月のイメージ]](#build.previous-image) に戻せます。 + 2024 年 3 月 26 日より前にワークフローに追加されたビルドアクションとテストアクションには、YAML 定義に `Container` セクションが*含まれない*ため、[[2022 年 11 月のイメージ]](#build.previous-image) が使用されます。2022 年 11 月のイメージを保持するか、アップグレードできます。イメージをアップグレードするには、ビジュアルエディタでアクションを開き、**[設定]** タブを選択し、**[Runtime 環境の docker イメージ]** ドロップダウンリストから 2024 年 3 月のイメージを選択します。この選択により、適切な 2024 年 3 月の画像が入力されているアクションの YAML 定義に `Container` セクションが追加されます。 + 他のすべてのアクションでは、[[2022 年 11 月のイメージ]](#build.previous-image) または [[2024 年 3 月のイメージ]](#build.default-image) が使用されます。詳細については、アクションのドキュメントを参照してください。 **Topics** + [ ### 2024 年 3 月のイメージ ](#build.default-image) + [ ### 2022 年 11 月のイメージ ](#build.previous-image) ### 2024 年 3 月のイメージ 2024 年 3 月のイメージは、CodeCatalyst が提供する最新のイメージです。2024 年 3 月には、コンピューティングタイプとフリートの組み合わせごとに 1 つのイメージがあります。次の表は、2024 年 3 月の各イメージにインストールされたツールを示しています。 **2024 年 3 月のイメージツール** | ツール | Linux x86\$164 用 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_x86_64:2024_03` | Linux x86\$164 用 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_x86_64:2024_03` | Linux Arm64 用 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_Arm64:2024_03` | Linux Arm64 用 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_Arm64:2024_03` | | --- | --- | --- | --- | --- | | AWS CLI | 2.15.17 | 2.15.17 | 2.15.17 | 2.15.17 | | AWS Copilot CLI | 1.32.1 | 1.32.1 | 1.32.1 | 1.32.1 | | Docker | 24.0.9 | 該当なし | 24.0.9 | 該当なし | | Docker Compose | 2.23.3 | 該当なし | 2.23.3 | 該当なし | | Git | 2.43.0 | 2.43.0 | 2.43.0 | 2.43.0 | | Go | 1.21.5 | 1.21.5 | 1.21.5 | 1.21.5 | | Gradle | 8.5 | 8.5 | 8.5 | 8.5 | | Java | Corretto17 | Corretto17 | Corretto17 | Corretto17 | | Maven | 3.9.6 | 3.9.6 | 3.9.6 | 3.9.6 | | Node.js | 18.19.0 | 18.19.0 | 18.19.0 | 18.19.0 | | npm | 10.2.3 | 10.2.3 | 10.2.3 | 10.2.3 | | Python | 3.9.18 | 3.9.18 | 3.9.18 | 3.9.18 | | Python3 | 3.11.6 | 3.11.6 | 3.11.6 | 3.11.6 | | pip | 22.3.1 | 22.3.1 | 22.3.1 | 22.3.1 | | .NET | 8.0.100 | 8.0.100 | 8.0.100 | 8.0.100 | ### 2022 年 11 月のイメージ 2022 年 11 月には、コンピューティングタイプとフリートの組み合わせごとに 1 つのイメージがあります。[[プロビジョニングされたフリート]](workflows-working-compute.md#compute.fleets) を設定している場合、ビルドアクションで 2022 年 11 月の Windows イメージも使用できます。次の表は、2022 年 11 月の各イメージにインストールされたツールを示しています。 **2022 年 11 月のイメージツール** | ツール | Linux x86\$164 用 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_x86_64:2022_11` | Linux x86\$164 用 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_x86_64:2022_11` | Linux Arm64 用 CodeCatalyst Amazon EC2 - `CodeCatalystLinux_Arm64:2022_11` | Linux Arm64 用 CodeCatalyst Lambda - `CodeCatalystLinuxLambda_Arm64:2022_11` | Windows x86\$164 用 CodeCatalyst Amazon EC2 - `CodeCatalystWindows_x86_64:2022_11` | | --- | --- | --- | --- | --- | --- | | AWS CLI | 2.15.17 | 2.15.17 | 2.15.17 | 2.15.17 | 2.13.19 | | AWS Copilot CLI | 0.6.0 | 0.6.0 | 該当なし | 該当なし | 1.30.1 | | Docker | 23.01 | 該当なし | 23.0.1 | 該当なし | 該当なし | | Docker Compose | 2.16.0 | 該当なし | 2.16.0 | 該当なし | 該当なし | | Git | 2.40.0 | 2.40.0 | 2.39.2 | 2.39.2 | 2.42.0 | | Go | 1.20.2 | 1.20.2 | 1.20.1 | 1.20.1 | 1.19 | | Gradle | 8.0.2 | 8.0.2 | 8.0.1 | 8.0.1 | 8.3 | | Java | Corretto17 | Corretto17 | Corretto17 | Corretto17 | Corretto17 | | Maven | 3.9.4 | 3.9.4 | 3.9.0 | 3.9.0 | 3.9.4 | | Node.js | 16.20.2 | 16.20.2 | 16.19.1 | 16.14.2 | 16.20.0 | | npm | 8.19.4 | 8.19.4 | 8.19.3 | 8.5.0 | 8.19.4 | | Python | 3.9.15 | 2.7.18 | 3.11.2 | 2.7.18 | 3.9.13 | | Python3 | 該当なし | 3.9.15 | 該当なし | 3.11.2 | 該当なし | | pip | 22.2.2 | 22.2.2 | 23.0.1 | 23.0.1 | 22.0.4 | | .NET | 6.0.407 | 6.0.407 | 6.0.406 | 6.0.406 | 6.0.414 | ## アクティブなイメージに必要なツールが含まれていない場合はどうなりますか？ CodeCatalyst が提供する [[アクティブなイメージ]](#build-curated-images) に、必要なツールが含まれていない場合は、いくつかのオプションがあります。 + 必要なツールを含むカスタムランタイム環境の Docker イメージを提供できます。詳細については、「[カスタムランタイム環境の Docker イメージをアクションに割り当てる](#build-images-specify)」を参照してください。 **注記** カスタムランタイム環境の Docker イメージを提供する場合は、カスタムイメージに Git がインストールされていることを確認してください。 + ワークフローのビルドまたはテストアクションに必要なツールをインストールできます。例えば、ビルドアクションまたはテストアクションの YAML コードの `Steps` セクションに以下の手順を含めることができます。 ``` Configuration: Steps: - Run: ./setup-script ``` *[setup-script]* 命令は、次のスクリプトを実行して Node パッケージマネージャー (npm) をインストールします。 ``` #!/usr/bin/env bash echo "Setting up environment" touch ~/.bashrc curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash source ~/.bashrc nvm install v16.1.0 source ~/.bashrc ``` アクションの使用方法の詳細については、「[ビルドおよびテストアクション YAML](build-action-ref.md)」を参照してください。 ## カスタムランタイム環境の Docker イメージをアクションに割り当てる CodeCatalyst が提供する [[アクティブイメージ]](#build-curated-images) を使用しない場合は、カスタムランタイム環境の Docker イメージを指定できます。カスタムイメージを提供する場合は、そのイメージに Git がインストールされていることを確認してください。イメージは、Docker Hub、Amazon Elastic Container Registry、または任意のパブリックリポジトリに格納できます。カスタム Docker イメージを作成する方法については、Docker ドキュメントの「[アプリケーションのコンテナ化](https://docs.docker.com/get-started/02_our_app/)」を参照してください。カスタムランタイム環境の Docker イメージをアクションに割り当てるには、次の手順に従います。イメージを指定すると、CodeCatalyst はアクションの開始時にそのイメージをコンピューティングプラットフォームにデプロイします。 **注記** 次のアクションは、カスタムランタイム環境の Docker イメージをサポートしていません: ** CloudFormation スタックのデプロイ**、**ECS へのデプロイ**、**GitHub Actions**。カスタムランタイム環境の Docker イメージは、**Lambda** コンピューティングタイプもサポートしていません。 ------ #### [ Visual ] **ビジュアルエディタを使用してカスタムランタイム環境の Docker イメージを割り当てるには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、カスタムランタイム環境の Docker イメージを使用するアクションを選択します。 1. **[設定]** タブを選択します。 1. 下部の近くで、次のフィールドに入力します。 **ランタイム環境 Docker イメージ - オプション** イメージが保存されているレジストリを指定します。有効な値を次に示します。 + `CODECATALYST` (YAML エディタ) イメージは CodeCatalyst レジストリに保存されます。 + **[Docker Hub]** (ビジュアルエディタ) または [`DockerHub`] (YAML エディタ) イメージは Docker Hub イメージレジストリに保存されます。 + **[その他のレジストリ]** (ビジュアルエディタ) または [`Other`] (YAML エディタ) イメージはカスタムイメージレジストリに保存されます。公開されているレジストリを使用できます。 + **[Amazon Elastic Container Registry]** (ビジュアルエディタ) または [`ECR`] (YAML エディタ) イメージは Amazon Elastic Container Registry イメージリポジトリに保存されます。Amazon ECR リポジトリでイメージを使用するには、このアクションで Amazon ECR にアクセスする必要があります。このアクセスを有効にするには、次のアクセス許可とカスタム信頼ポリシーを含む [[IAM ロール]](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) を作成する必要があります。(既存のロールを変更して、必要に応じてアクセス許可とポリシーを含めることができます。) IAM ロールのロールポリシーには、次のアクセス許可を含める必要があります。 + `ecr:BatchCheckLayerAvailability` + `ecr:BatchGetImage` + `ecr:GetAuthorizationToken` + `ecr:GetDownloadUrlForLayer` IAM ロールには、次のカスタム信頼ポリシーを含める必要があります。 IAM ロールの作成に関する詳細については、「*IAM ユーザーガイド*」の「[ロールの作成とポリシーのアタッチ (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)」を参照してください。ロールを作成したら、環境を介してアクションに割り当てる必要があります。詳細については、「[環境とアクションの関連付け](deploy-environments-add-app-to-environment.md)」を参照してください。 **[ECR イメージ URL]**、**[Docker Hub イメージ]**、または **[イメージ URL]** 次のいずれかを指定します。 + `CODECATALYST` レジストリを使用している場合は、イメージを次のいずれかの [[アクティブなイメージ]](#build-curated-images) に設定します。 + `CodeCatalystLinux_x86_64:2024_03` + `CodeCatalystLinux_x86_64:2022_11` + `CodeCatalystLinux_Arm64:2024_03` + `CodeCatalystLinux_Arm64:2022_11` + `CodeCatalystLinuxLambda_x86_64:2024_03` + `CodeCatalystLinuxLambda_x86_64:2022_11` + `CodeCatalystLinuxLambda_Arm64:2024_03` + `CodeCatalystLinuxLambda_Arm64:2022_11` + `CodeCatalystWindows_x86_64:2022_11` + Docker Hub レジストリを使用している場合は、イメージを Docker Hub イメージ名とオプションのタグに設定します。例: `postgres:latest` + Amazon ECR レジストリを使用している場合は、イメージを Amazon ECR レジストリ URI に設定します。例: `111122223333.dkr.ecr.us-west-2.amazonaws.com/codecatalyst-ecs-image-repo` + カスタムレジストリを使用している場合は、イメージをカスタムレジストリで期待される値に設定します。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用してカスタムランタイム環境の Docker イメージを割り当てるには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ランタイム環境の Docker イメージを割り当てるアクションを見つけます。 1. アクションで、`Container` セクションと基盤となる `Registry` プロパティと `Image` プロパティを追加します。詳細については、「`Container`」、「`Registry`」、およびアクションの [アクション](workflow-reference.md#actions-reference) の `Image` プロパティの説明を参照してください。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ ## 例次の例は、カスタムランタイム環境の Docker イメージをワークフロー定義ファイルのアクションに割り当てる方法を示しています。 **Topics** + [ ### 例: Amazon ECR でカスタムランタイム環境 Docker イメージを使用して Node.js 18 のサポートを追加する ](#workflows-working-custom-image-ex-ecr-node18) + [ ### 例: カスタムランタイム環境の Docker イメージを使用して、Docker Hub で Node.js 18 のサポートを追加する ](#workflows-working-custom-image-ex-docker-node18) ### 例: Amazon ECR でカスタムランタイム環境 Docker イメージを使用して Node.js 18 のサポートを追加する次の例は、カスタムランタイム環境 Docker イメージを使用して [[Amazon ECR]](https://gallery.ecr.aws/amazonlinux/amazonlinux) で Node.js 18 のサポートを追加する方法を示しています。 ``` Configuration: Container: Registry: ECR Image: public.ecr.aws/amazonlinux/amazonlinux:2023 ``` ### 例: カスタムランタイム環境の Docker イメージを使用して、Docker Hub で Node.js 18 のサポートを追加する次の例は、カスタムランタイム環境 Docker イメージを使用して [[Docker Hub]](https://hub.docker.com/_/node) で Node.js 18 のサポートを追加する方法を示しています。 ``` Configuration: Container: Registry: DockerHub Image: node:18.18.2 ``` # ワークフローへのソースリポジトリの接続 *ソース*は*入力ソース*とも呼ばれ、[ワークフローアクション](workflows-actions.md)がオペレーションの実行に必要なファイルを取得するために接続するソースリポジトリです。例えば、ワークフローアクションがソースリポジトリに接続して、アプリケーションを構築するためにアプリケーションソースファイルを取得する場合があります。 CodeCatalyst ワークフローでは次のソースをサポートしています。 + CodeCatalyst ソースリポジトリ — 詳細については、「[CodeCatalyst のソースリポジトリでコードを保存し、共同作業を行うソースリポジトリでコードを保存して共同作業を行う](source.md)」を参照してください。 + GitHub リポジトリ、Bitbucket リポジトリ、GitLab プロジェクトリポジトリ – 詳細については、「[CodeCatalyst で拡張機能を持つプロジェクトに機能を追加する拡張機能を使用してプロジェクトに機能を追加する](extensions.md)」を参照してください。 **Topics** + [ # ワークフローファイルのソースリポジトリの指定 ](workflows-sources-specify-workflow-def.md) + [ # ワークフローアクションのソースリポジトリの指定 ](workflows-sources-specify-action.md) + [ # ソースリポジトリファイルの参照 ](workflows-sources-reference-files.md) + [ # 「BranchName」変数と「CommitId」変数 ](workflows-sources-variables.md) # ワークフローファイルのソースリポジトリの指定次の手順に従って、ワークフロー定義ファイルを保存する CodeCatalyst ソースリポジトリを指定します。GitHub リポジトリ、Bitbucket リポジトリ、または GitLab プロジェクトリポジトリを指定する場合は、代わりに「[CodeCatalyst で拡張機能を持つプロジェクトに機能を追加する拡張機能を使用してプロジェクトに機能を追加する](extensions.md)」を参照してください。ワークフロー定義ファイルが存在するソースリポジトリには「`WorkflowSource`」というラベルが付きます。 **注記** ワークフロー定義ファイルを最初にコミットするときに、ワークフロー定義ファイルが存在するソースリポジトリを指定します。このコミットの後、リポジトリとワークフロー定義ファイルは永続的に相互リンクされます。最初のコミットの後にリポジトリを変更する唯一の方法は、別のリポジトリでワークフローを再作成することです。 **ワークフロー定義ファイルを保存するソースリポジトリを指定するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフローの作成]** を選択してワークフローを作成します。詳細については、「[ワークフローの作成](workflows-create-workflow.md)」を参照してください。ワークフロー作成プロセス中に、ワークフロー定義ファイルを保存する CodeCatalyst リポジトリ、ブランチ、フォルダを指定できます。 # ワークフローアクションのソースリポジトリの指定次の手順に従って、ワークフローアクションで使用するソースリポジトリを指定します。起動時に、アクションは構成済みソースリポジトリのファイルをアーティファクトにバンドルし、アクションが実行されている[ランタイム環境の Docker イメージ](build-images.md)にアーティファクトをダウンロードし、ダウンロードしたファイルを使用して処理を完了します。 **注記** 現在、ワークフローアクション内で指定できるのは 1 つのソースリポジトリのみです。これは、ワークフロー定義ファイルが存在するソースリポジトリです (`.codecatalyst/workflows/` ディレクトリまたはそのサブディレクトリのいずれかの中)。このソースリポジトリには `WorkflowSource` というラベルが付きます。 ------ #### [ Visual ] **アクションで使用するソースリポジトリを指定するには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、ソースを指定するアクションを選択します。 1. **[入力]** を選択します。 1. **[ソース - 省略可]** で以下を実行します。アクションに必要なソースリポジトリを表すラベルを指定します。現在、サポートされているラベルは `WorkflowSource` のみです。これは、ワークフロー定義ファイルが保存されているソースリポジトリを表します。ソースを省略する場合は、`action-name/Inputs/Artifacts` で少なくとも 1 つの入力アーティファクトを指定する必要があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **アクションで使用するソースリポジトリを指定するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. アクションで、次のようなコードを追加します。 ``` action-name: Inputs: Sources: - WorkflowSource ``` 詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」の `Sources` プロパティの説明を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # ソースリポジトリファイルの参照ソースリポジトリにファイルがあり、ワークフローアクションのいずれかでこれらのファイルを参照する必要がある場合は、次の手順を実行します。 **注記** [アーティファクト内のファイルの参照](workflows-working-artifacts-refer-files.md) も参照してください。 **ソースリポジトリに保存されているファイルを参照するには** + ファイルを参照するアクションで、次のようなコードを追加します。 ``` Actions: My-action: Inputs: Sources: - WorkflowSource Configuration: Steps: - run: cd my-app && cat file1.jar ``` 前のコードでは、アクションが `WorkflowSource` ソースリポジトリのルートにある `my-app` ディレクトリを検索し、`file1.jar` ファイルを見つけて表示します。 # 「BranchName」変数と「CommitId」変数 CodeCatalyst ソースでは、ワークフローの実行時に `BranchName` 変数と `CommitId` 変数を生成および設定します。これらは*事前定義済み変数*と呼ばれます。これらの変数の詳細については、以下の表を参照してください。ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください。 | キー | 値 | | --- | --- | | CommitId | ワークフロー実行開始時のリポジトリの状態を表すコミット ID。例: `example3819261db00a3ab59468c8b` 「[例: 「CommitId」事前定義済み変数の参照](workflows-predefined-examples.md#workflows-working-with-variables-ex-refer-action)」も参照してください。 | | BranchName | ワークフローの実行が開始されたブランチの名前。例: `main`、`feature/branch`、`test-LiJuan` 「[例: 「BranchName」事前定義済み変数の参照](workflows-predefined-examples.md#workflows-working-with-variables-ex-branch)」も参照してください。 | # ワークフローへのパッケージリポジトリの接続 *パッケージ*とは、ソフトウェアと、ソフトウェアのインストールおよび依存関係の解決に必要なメタデータの両方を含むバンドルです。CodeCatalyst は npm パッケージ形式をサポートしています。パッケージの内容は以下のとおりです。 + 名前 (例: `webpack` はよく利用されている npm パッケージの名前です) + オプションの[名前空間](packages-concepts.md#packages-concepts-package-namespaces) (`@types/node` の `@types` など) + 一連の[バージョン](packages-concepts.md#packages-concepts-package-versions) (`1.0.0`、`1.0.1`、`1.0.2` など) + パッケージレベルのメタデータ (npm ディストリビューションタグなど) CodeCatalyst では、ワークフローで CodeCatalyst パッケージリポジトリにパッケージを発行し、そのパッケージを使用することができます。CodeCatalyst パッケージリポジトリを使用してビルドアクションまたはテストアクションを構成して、指定されたリポジトリからパッケージをプッシュおよびプルするようにアクションの npm クライアントを自動的に構成できます。パッケージの詳細については、「[CodeCatalyst でソフトウェアパッケージを公開および共有する](packages.md)」を参照してください。 **注記** 現在、ビルドアクションとテストアクションで CodeCatalyst パッケージリポジトリをサポートしています。 **Topics** + [ # チュートリアル: パッケージリポジトリからプルする ](packages-tutorial.md) + [ # ークフローでの CodeCatalyst パッケージリポジトリを指定する ](workflows-package-specify-action.md) + [ # ワークフローアクションでの認証トークンの使用 ](workflows-package-export-token.md) + [ # 例: ワークフローのパッケージリポジトリ ](workflows-working-packages-ex.md) # チュートリアル: パッケージリポジトリからプルするこのチュートリアルでは、[CodeCatalyst パッケージリポジトリ](packages-concepts.md#packages-concepts-repository)から依存関係をプルするアプリケーションを実行するワークフローの作成手順を説明します。アプリケーションは、CodeCatalyst ログに「Hello World」メッセージを出力するシンプルな Node.js アプリケーションです。アプリケーションには [lodash](https://www.npmjs.com/package/lodash) npm パッケージという 1 つの依存関係があります。`lodash` パッケージは、`hello-world` 文字列を `Hello World` に変換するために使用されます。このパッケージのバージョン 4.17.20 を使用します。アプリケーションとワークフローを準備したら、CodeCatalyst を設定して `lodash` の他のバージョンをブロックし、外部のパブリックレジストリ ([npmjs.com](https://www.npmjs.com/)) から CodeCatalyst パッケージリポジトリにインポートされないようにします。その後、`lodash` の他のバージョンが正常にブロックされているかどうかテストします。このチュートリアルを完了すると、ワークフローが CodeCatalyst 内外のパッケージリポジトリとどのようにやりとりし、パッケージを取得するのかを十分に理解できます。また、npm、パッケージリポジトリ、ワークフロー、アプリケーションの `package.json` ファイルの間で発生する裏側のやりとりについても理解することができます。 **Topics** + [ ## 前提条件 ](#packages-tutorial-prereqs) + [ ## ステップ 1: ソースレポジトリを作成する ](#packages-tutorial-source-repo) + [ ## ステップ 2: CodeCatalyst パッケージリポジトリとゲートウェイパッケージリポジトリを作成する ](#packages-tutorial-package-repo) + [ ## ステップ 3: 「Hello World」アプリケーションを作成する ](#packages-tutorial-create-app) + [ ## ステップ 4:「Hello World」を実行するワークフローを作成する ](#packages-tutorial-create-workflow) + [ ## ステップ 5: ワークフローを検証する ](#packages-tutorial-verify) + [ ## ステップ 6: npmjs.com からのインポートをブロックする ](#packages-tutorial-block) + [ ## ステップ 7: ブロック機能をテストする ](#packages-tutorial-test-block) + [ ## クリーンアップ ](#packages-tutorial-cleanup) ## 前提条件開始する前に: + CodeCatalyst **スペース**が必要です。詳細については、「[スペースを作成する](spaces-create.md)」を参照してください。 + CodeCatalyst スペースに、次の名前を持つ空のプロジェクトが必要です。 ``` codecatalyst-package-project ``` このプロジェクトを作成するには、**[ゼロから開始]** オプションを使用します。詳細については、「[Amazon CodeCatalyst での空のプロジェクトの作成](projects-create.md#projects-create-empty)」を参照してください。 ## ステップ 1: ソースレポジトリを作成するこのステップでは、CodeCatalyst に空のソースリポジトリを作成します。このリポジトリには、`index.js` や `package.json` など、チュートリアルのソースファイルが保存されます。ソースリポジトリの詳細については、「[ソースリポジトリを作成する](source-repositories-create.md)」を参照してください。 **ソースリポジトリを作成するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクト「`codecatalyst-package-project`」に移動します。 1. ナビゲーションペインで **[コード]** を選択してから、**[ソースリポジトリ]** を選択します。 1. **[リポジトリの追加]** を選択し、**[リポジトリの作成]** を選択します。 1. **[リポジトリ名]** に次のように入力します。 ``` hello-world-app ``` 1. **[作成]** を選択します。 ## ステップ 2: CodeCatalyst パッケージリポジトリとゲートウェイパッケージリポジトリを作成するこのステップでは、CodeCatalyst プロジェクトにパッケージリポジトリを作成します。また、CodeCatalyst プロジェクトでゲートウェイリポジトリにも接続します。その後、チュートリアルの依存関係 `lodash` を npmjs.com から両方のリポジトリにインポートします。ゲートウェイリポジトリとは、CodeCatalyst のパッケージリポジトリをパブリック npmjs.com に接続する接着剤のようなものです。パッケージリポジトリの作成方法については、「[CodeCatalyst でソフトウェアパッケージを公開および共有する](packages.md)」を参照してください。 **注記** このチュートリアルでは、以下の手順で CodeCatalyst で作成する 2 つのリポジトリを指す用語として、*CodeCatalyst パッケージリポジトリ*と*ゲートウェイリポジトリ*を使用します。 **CodeCatalyst パッケージリポジトリとゲートウェイリポジトリを作成するには** 1. ナビゲーションペインで、[**Packages (パッケージ)**] を選択します。 1. **[パッケージリポジトリの作成]** を選択します。 1. **[リポジトリ名]** に次のように入力します。 ``` codecatalyst-package-repository ``` 1. **[\$1アップストリームリポジトリを選択]** を選択します。 1. **[ゲートウェイリポジトリ]** を選択します。 1. **[npm-public-registry-gateway]** ボックスで、**[作成]** を選択します。 1. **[選択]** を選択します。 1. **[作成]** を選択します。 CodeCatalyst により、ゲートウェイリポジトリに接続されている `codecatalyst-package-repository` というパッケージリポジトリが作成されます。ゲートウェイリポジトリは npmjs.com レジストリに接続されています。 ## ステップ 3: 「Hello World」アプリケーションを作成するこのステップでは、「Hello World」 Node.js アプリケーションを作成し、その依存関係 (`lodash`) をゲートウェイリポジトリと CodeCatalyst パッケージリポジトリにインポートします。このアプリケーションを作成するには、Node.js と、関連する `npm` クライアントがインストールされている開発マシンが必要です。このチュートリアルでは、CodeCatalyst 開発環境を開発マシンとして使用することを前提としています。CodeCatalyst 開発環境を使用する必要はありませんが、クリーンな作業環境が用意され、Node.js と `npm` がプリインストールされているうえに、チュートリアル終了後は簡単に削除できるため、使用することをお勧めします。CodeCatalyst 開発環境の詳細については、「[開発環境の作成](devenvironment-create.md)」を参照してください。次の手順に従って CodeCatalyst 開発環境を立ち上げ、この開発環境を使用して「Hello World」アプリケーションを作成します。 **CodeCatalyst 開発環境を立ち上げるには** 1. ナビゲーションペインで、**[コード]**、**[開発環境]** の順に選択します。 1. 上部近くで **[開発環境を作成]** を選択し、**[AWS Cloud9 (ブラウザで)]** を選択します。 1. **[リポジトリ]** が `hello-world-app` に設定され、**[既存のブランチ]** が `main` に設定されていることを確認します。**[作成]** を選択します。開発環境が新しいブラウザタブで起動し、リポジトリ (`hello-world-app`) のクローンがそこに作成されます。 1. 両方の CodeCatalyst ブラウザタブを開いたままにして、次の手順に進みます。 **「Hello World」Node.js アプリケーションを作成するには** 1. 開発環境に移動します。 1. ターミナルプロンプトで、`hello-world-app` ソースリポジトリのルートディレクトリに変更します。 ``` cd hello-world-app ``` 1. Node.js プロジェクトを初期化します。 ``` npm init -y ``` 初期化により、`hello-world-app` のルートディレクトリに `package.json` ファイルが作成されます。 1. 開発環境の npm クライアントを CodeCatalyst パッケージリポジトリに接続します。 1. CodeCatalyst コンソールに切り替えます。 1. ナビゲーションペインで、[**Packages (パッケージ)**] を選択します。 1. `codecatalyst-package-repository` を選択してください。 1. **[リポジトリに接続]** を選択します。 1. **[トークンを作成]** をクリックします。個人用アクセストークン (PAT) が作成されます。 1. **[コピー]** を選択してコマンドをコピーします。 1. 開発環境に切り替えます。 1. `hello-world-app` ディレクトリにいることを確認します。 1. コマンドを貼り付けます。次のような内容です。 ``` npm set registry=https://packages.us-west-2.codecatalyst.aws/npm/ExampleCompany/codecatalyst-package-project/codecatalyst-package-repository/ --location project npm set //packages.us-west-2.codecatalyst.aws/npm/ExampleCompany/codecatalyst-package-project/hello-world-app/:_authToken=username:token-secret ``` 1. `lodash` バージョン 4.17.20 をインストールします。 ``` npm install lodash@v4.17.20 --save --save-exact ``` npm は、次の場所で `lodash` バージョン 4.17.20 を次の順序で検索します。 + 開発環境。ここにはありません。 + CodeCatalyst パッケージリポジトリ。ここにはありません。 + ゲートウェイリポジトリ。ここにはありません。 + npmjs.com。ここにあります。 npm は、`lodash` をゲートウェイリポジトリ、CodeCatalyst パッケージリポジトリ、開発環境にインポートします。 **注記** ステップ 4 で npm クライアントを CodeCatalyst パッケージリポジトリに接続していなければ、npm は `lodash` を npmjs.com から直接プルし、パッケージはどちらのリポジトリにもインポートされることはありません npm は、`lodash` 依存関係を使用して `package.json` ファイルも更新し、`lodash` とそのすべての依存関係を含む `node_modules` ディレクトリを作成します。 1. `lodash` が開発環境に正常にインポートされたことを確認します。次のとおりに入力します。 ``` npm list ``` インポートが成功したことを示す次のメッセージが表示されます。 ``` `-- lodash@4.17.20 ``` 1. (オプション) `hello-world-app/package.json` を開き、***赤い太字***の行が追加されていることを確認します。 ``` { "name": "hello-world-app", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC", dependencies": { "lodash": "4.17.20" } } ``` 1. `/hello-world-app` に「`index.js`」という名前のファイルを次の内容で作成します。 **ヒント** このファイルを作成するには、開発環境のサイドナビゲーションを使用します。 ``` // Importing lodash library const _ = require('lodash'); // Input string const inputString = 'hello-world'; // Transforming the string using lodash const transformedString = _.startCase(inputString.replace('-', ' ')); // Outputting the transformed string to the console console.log(transformedString); ``` **「lodash」がゲートウェイリポジトリと CodeCatalyst パッケージリポジトリにインポートされたことをテストするには** 1. CodeCatalyst コンソールに切り替えます。 1. ナビゲーションペインで、[**Packages (パッケージ)**] を選択します。 1. **[npm-public-registry-gateway]** を選択します。 1. `lodash` が表示されていることを確認します。**[最新バージョン]** の列には `4.17.20` が表示されます。 1. `codecatalyst-package-repository` でこの手順を繰り返します。インポートされたパッケージを表示するには、ブラウザウィンドウを再読み込みする必要があるかもしれません。 **開発環境で「Hello World」をテストするには** 1. 開発環境に切り替えます。 1. 引き続き `hello-world-app` ディレクトリにいることを確認し、アプリケーションを実行します。 ``` node index.js ``` `Hello World` メッセージが表示されます。Node.js は、前のステップで開発環境にダウンロードした `lodash` パッケージを使用してアプリケーションを実行しました。 **「node\$1modules」ディレクトリを無視して「Hello World」をコミットするには** 1. `node_modules` ディレクトリを無視します。次のとおりに入力します。 ``` echo "node_modules/" >> .gitignore ``` このディレクトリをコミットしないことをお勧めします。また、このディレクトリをコミットすると、このチュートリアルの後のステップに支障をきたします。 1. 追加、コミット、プッシュ: ``` git add . git commit -m "add the Hello World application" git push ``` 「Hello World」アプリケーションファイルとプロジェクトファイルがソースリポジトリに追加されます。 ## ステップ 4:「Hello World」を実行するワークフローを作成するこのステップでは、`lodash` 依存関係を使用して「Hello World」アプリケーションを実行するワークフローを作成します。ワークフローには、`RunHelloWorldApp` と呼ばれる 1 つの*アクション*、またはタスクが含まれています。`RunHelloWorldApp` アクションに含まれる主なコマンドとセクション: + **`Packages`** このセクションには、`npm install` の実行時にアクションが接続する必要がある CodeCatalyst パッケージリポジトリの名前が示されています。 + **`- Run: npm install`** このコマンドは、`package.json` ファイルで指定された依存関係をインストールするように npm に指示します。`package.json` ファイルで指定されている依存関係は `lodash` のみです。npm は、次の場所で `lodash` を検索します。 + アクションを実行している Docker イメージ。ここにはありません。 + CodeCatalyst パッケージリポジトリ。ここにあります。 npm が `lodash` を検出すると、アクションを実行している Docker イメージにインポートされます。 + **`- Run: npm list`** このコマンドは、アクションを実行している Docker イメージにダウンロードされた `lodash` のバージョンを出力します。 + **`- Run: node index.js`** このコマンドは、`package.json` ファイルで指定された依存関係を使用して「Hello World」アプリケーションを実行します。 `RunHelloWorldApp` アクションはビルドアクションであることに注目してください。これは、ワークフローの上部にある `aws/build@v1` 識別子でわかります。うに、ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。次の手順を使用して、CodeCatalyst パッケージリポジトリから `lodash` 依存関係をプルし、「Hello World」アプリケーションを実行するワークフローを作成します。 **ワークフローを作成するには** 1. CodeCatalyst コンソールに切り替えます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. **[ワークフローを作成]** を選択します。 1. **[ソースリポジトリ]** で、`hello-world-app` を選択します。 1. **[ブランチ]** で、`main` を選択します。ワークフロー定義ファイルは、選択したソースリポジトリとブランチに作成されます。 1. **[作成]** を選択します。 1. 上部付近の **[YAML]** を選択します。 1. YAML サンプルコードを削除します。 1. 次の YAML コードを追加します。 ``` Name: codecatalyst-package-workflow SchemaVersion: "1.0" # Required - Define action configurations. Actions: RunHelloWorldApp: # Identifies the action. Do not modify this value. Identifier: aws/build@v1 Compute: Type: Lambda Inputs: Sources: - WorkflowSource # This specifies your source repository. Configuration: Steps: - Run: npm install - Run: npm list - Run: node index.js Container: # This specifies the Docker image that runs the action. Registry: CODECATALYST Image: CodeCatalystLinuxLambda_x86_64:2024_03 Packages: NpmConfiguration: PackageRegistries: - PackagesRepository: codecatalyst-package-repository ``` 上記のコードで、*codecatalyst-package-repository* を、「[ステップ 2: CodeCatalyst パッケージリポジトリとゲートウェイパッケージリポジトリを作成する](#packages-tutorial-package-repo)」で作成した CodeCatalyst パッケージリポジトリの名前に置き換えます。このファイルのプロパティの詳細については、「[ビルドおよびテストアクション YAML](build-action-ref.md)」を参照してください。 1. (任意) **[検証]** を選択して、コミットする前に YAML コードが有効であることを確認します。 1. **[コミット]** を選択します。 1. **[ワークフローをコミット]** ダイアログボックスで、次のように入力します。 1. **[ワークフローファイル名]** は、デフォルトの「`codecatalyst-package-workflow`」のままにします。 1. **[コミットメッセージ]** には、次のように入力します。 ``` add initial workflow file ``` 1. **[リポジトリ]** で、**[hello-world-app]** を選択します。 1. **[ブランチ名]** で、**[main]** を選択します。 1. **[コミット]** を選択します。これでワークフローが作成されました。 **ワークフローを実行するには** 1. 先ほど作成したワークフロー (`codecatalyst-package-workflow`) の横にある **[アクション]** を選択し、**[実行]** を選択します。ワークフローの実行が開始されます。 1. 右上の緑色の通知で、実行へのリンクをクリックします。リンクは `View Run-1234` の形式で表示されます。ワークフロー図が表示され、実行を開始したユーザーと **RunHelloWorldApp** アクションが表示されます。 1. **[RunHelloWorldApp]** アクションボックスを選択して、アクションの進行状況を確認します。 1. 実行が完了したら、「[ステップ 5: ワークフローを検証する](#packages-tutorial-verify)」に進みます。 ## ステップ 5: ワークフローを検証するこのステップでは、ワークフローが「Hello World」アプリケーションをその `lodash` 依存関係を使用して正常に実行したことを確認します。 **「Hello World」アプリケーションが依存関係を使用して実行されたことを確認するには** 1. ワークフロー図で、**[RunHelloWorldApp]** ボックスを選択します。ログメッセージのリストが表示されます。 1. `node index.js` ログメッセージを展開します。次のメッセージが表示されます。 ``` [Container] 2024/04/24 21:15:41.545650 Running command node index.js Hello World ``` `hello-world` ではなく `Hello Word` と表示されていることから、`lodash` 依存関係が正常に使用されたことがわかります。 1. `npm list` ログを展開します。次のようなメッセージが表示されます。 ``` └── lodash@4.17.20 ``` このメッセージは、ワークフローアクションを実行している Docker イメージに `lodash` バージョン 4.17.20 がダウンロードされたことを示しています。 ## ステップ 6: npmjs.com からのインポートをブロックする `lodash` バージョン 4.17.20 がゲートウェイリポジトリと CodeCatalyst パッケージリポジトリに存在するため、他のバージョンのインポートをブロックできます。ブロックすると、悪意のあるコードが含まれている可能性がある `lodash` のそれ以降 (またはそれ以前の) バージョンを誤ってインポートできなくなります。詳細については、「[パッケージオリジンコントロールの編集](package-origin-controls.md)」および「[依存関係置換攻撃](package-origin-controls.md#dependency-substitution-attacks)」を参照してください。ゲートウェイリポジトリへの `lodash` のインポートをブロックする手順は次のとおりです。ゲートウェイでパッケージをブロックすると、ダウンストリームの場所でもブロックされます。 **ゲートウェイリポジトリへのインポートをブロックするには** 1. ナビゲーションペインで、[**Packages (パッケージ)**] を選択します。 1. **[npm-publish-registry-gateway]** を選択します。 1. `lodash` を選択してください。 1. 上部付近で、**[オリジンコントロール]** を選択します。 1. **[アップストリーム]** で、**[ブロック]** を選択します。 1. **[保存]** を選択します。これで、npmjs.com からゲートウェイリポジトリ (およびダウンストリームリポジトリとコンピュータ) へのインポートがブロックされました。 ## ステップ 7: ブロック機能をテストするこのセクションでは、「[ステップ 6: npmjs.com からのインポートをブロックする](#packages-tutorial-block)」で設定したブロックが機能していることを確認します。まず、「Hello World」を、ゲートウェイリポジトリで使用可能な `lodash` のバージョン 4.17.2**0** ではなく、バージョン 4.17.2**1** をリクエストするように設定します。次に、アプリケーションが nmpjs.com からバージョン 4.17.21 をプルできないことを確認します。これは、ブロックが成功したことを意味します。最後のテストとして、ゲートウェイリポジトリへのインポートのブロックを解除し、アプリケーションが `lodash` のバージョン 4.17.21 を正常にプルできることを確認します。ブロック機能をテストするには、以下の手順を使用します。 **[開始する前に]** 1. 開発環境に切り替えます。 1. CodeCatalyst コンソールを使用して以前に作成した `codecatalyst-package-workflow.yaml` ファイルをプルします。 ``` git pull ``` **「lodash」のバージョン 4.17.21 をリクエストするように「Hello World」を設定するには** 1. `/hello-world-app/package.json` を開きます。 1. ***赤の太字***で示されているように、`lodash` のバージョンを 4.17.21 に変更します。 ``` { "name": "hello-world-app", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC", "dependencies": { "lodash": "4.17.21" } } ``` これで、`package.json` ファイル内のバージョン (4.17.21) とゲートウェイリポジトリおよび CodeCatalyst パッケージリポジトリ内のバージョン (4.17.20) が一致しなくなりました。 1. 追加、コミット、プッシュ: ``` git add . git commit -m "update package.json to use lodash 4.17.21" git push ``` **「Hello World」が「lodash」のバージョン 4.17.21 をプルできないことをテストするには** 1. バージョンが一致しない状態でワークフローを実行します。 1. CodeCatalyst コンソールに切り替えます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. `codecatalyst-package-workflow` の横で、**[アクション]**、**[実行]** の順に選択します。 npm は `package.json` で依存関係をチェックし、`lodash` のバージョン 4.17.21 が「Hello World」で必要であることを確認します。npm は、次の場所で、次の順序で依存関係を探します。 + アクションを実行している Docker イメージ。ここにはありません。 + CodeCatalyst パッケージリポジトリ。ここにはありません。 + ゲートウェイリポジトリ。ここにはありません。 + npmjs.com。ここにあります。 npm が npmjs.com でバージョン 4.17.21 を見つけた後、ゲートウェイリポジトリにインポートしようとしますが、`lodash` のインポートをブロックするようにゲートウェイを設定しているため、インポートは行われません。インポートが行われないため、ワークフローは失敗します。 1. ワークフローが失敗したことを確認します。 1. 右上の緑色の通知で、実行へのリンクをクリックします。リンクは `View Run-2345` の形式で表示されます。 1. ワークフロー図で、**[RunHelloWorldApp]** ボックスを選択します。 1. `npm install` ログメッセージを展開します。次のメッセージが表示されます。 ``` [Container] 2024/04/25 17:20:34.995591 Running command npm install npm ERR! code ETARGET npm ERR! notarget No matching version found for lodash@4.17.21. npm ERR! notarget In most cases you or one of your dependencies are requesting npm ERR! notarget a package version that doesn't exist. npm ERR! A complete log of this run can be found in: /tmp/.npm/_logs/2024-05-08T22_03_26_493Z-debug-0.log ``` エラーから、バージョン 4.17.21 が見つからなかったことがわかります。ブロックしているので、想定される結果です。 **npmjs.com からのインポートのブロックを解除するには** 1. ナビゲーションペインで、[**Packages (パッケージ)**] を選択します。 1. **[npm-publish-registry-gateway]** を選択します。 1. `lodash` を選択してください。 1. 上部付近で、**[オリジンコントロール]** を選択します。 1. **[アップストリーム]** で、**[許可]** を選択します。 1. **[保存]** を選択します。これで、`lodash` のインポートのブロックが解除されました。ワークフローで `lodash` のバージョン 4.17.21 をインポートできるようになりました。 **npmjs.com からのインポートがブロック解除されていることをテストするには** 1. ワークフローを再度実行します。4.17.21 のインポートが機能するようになったため、今回はワークフローが成功するはずです。ワークフローを再び実行するには: 1. **[CI/CD]** を選択し、**[ワークフロー]** を選択します。 1. `codecatalyst-package-workflow` の横で、**[アクション]**、**[実行]** の順に選択します。 1. 右上の緑色の通知で、実行へのリンクをクリックします。リンクは `View Run-3456` の形式で表示されます。ワークフロー図が表示され、実行を開始したユーザーと **RunHelloWorldApp** アクションが表示されます。 1. **[RunHelloWorldApp]** アクションボックスを選択して、アクションの進行状況を確認します。 1. `npm list` ログメッセージを展開し、次のようなメッセージが表示されることを確認します。 ``` └── lodash@4.17.21 ``` このメッセージから、`lodash` バージョン 4.17.21 がダウンロードされたことがわかります。 1. バージョン 4.17.21 が CodeCatalyst およびゲートウェイリポジトリにインポートされたことを確認します。 1. ナビゲーションペインで、[**Packages (パッケージ)**] を選択します。 1. **[npm-public-registry-gateway]** を選択します。 1. `lodash` を見つけて、バージョンが `4.17.21` であることを確認します。 **注記** バージョン 4.17.20 はこのページに表示されていませんが、`lodash` を選択して、上部にある **[バージョン]** を選択することで見つけることができます。 1. 以上のステップを繰り返して、バージョン 4.17.21 がにインポートされたことを確認します`codecatalyst-package-repository`。 ## クリーンアップこのチュートリアルで使用されているファイルとサービスをクリーンアップして、料金が発生しないようにします。 **パッケージのチュートリアルをクリーンアップするには** 1. `codecatalyst-package-project` を削除する: 1. CodeCatalyst コンソールで、まだ `codecatalyst-package-project` プロジェクトにいない場合はプロジェクトに移動します。 1. ナビゲーションペインで、**[プロジェクト設定]** を選択します。 1. **[プロジェクトの削除]** を選択し、「**delete**」と入力し、**[プロジェクトの削除]** を選択します。 CodeCatalyst は、ソースリポジトリ、ゲートウェイリポジトリ、CodeCatalyst パッケージリポジトリを含むすべてのプロジェクトリソースを削除します。開発環境も削除されます。 1. PAT トークンを削除する: 1. 右側のユーザー名を選択し、**[マイ設定]** を選択します。 1. **[個人用アクセストークン]** で、このチュートリアルで作成したトークンを選択し、**[削除]** を選択します。このチュートリアルでは、CodeCatalyst パッケージリポジトリから依存関係をプルするアプリケーションを実行するワークフローの作成手順を学びました。また、パッケージがゲートウェイリポジトリや CodeCatalyst パッケージリポジトリに入るのをブロックする方法や、そのブロックを解除する方法も学びました。 # ークフローでの CodeCatalyst パッケージリポジトリを指定する CodeCatalyst では、ワークフローのビルドアクションとテストアクションに CodeCatalyst パッケージリポジトリを追加できます。パッケージリポジトリは、npm などのパッケージ形式で構成する必要があります。選択したパッケージリポジトリのスコープのシーケンスを含めることもできます。次の手順に従って、ワークフローアクションで使用するパッケージ構成を指定します。 ------ #### [ Visual ] **アクションで使用するパッケージ構成を指定するには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、パッケージリポジトリで構成する**ビルド**または**テスト**アクションを選択します。 1. **[パッケージ]** を選択します。 1. **[構成を追加]** ドロップダウンメニューから、ワークフローアクションで使用するパッケージ構成を選択します。 1. **[パッケージリポジトリの追加]** を選択します。 1. **[パッケージリポジトリ]** ドロップダウンメニューで、アクションで使用する CodeCatalyst *パッケージリポジトリ*の名前を指定します。パッケージリポジトリの作成方法については、「[パッケージリポジトリ](packages-concepts.md#packages-concepts-repository)」を参照してください。 1. (省略可) **[スコープ - 省略可]** で、パッケージレジストリで定義する*スコープ*のシーケンスを指定します。スコープを定義する場合、指定されたパッケージリポジトリは、一覧表示されているすべてのスコープのレジストリとして構成されます。スコープを持つパッケージが npm クライアントを介してリクエストされた場合、デフォルトの代わりにそのリポジトリが使用されます。各スコープ名には、「@」というプレフィックスを付ける必要があります。 `Scopes` を省略すると、指定されたパッケージリポジトリは、アクションで使用されるすべてのパッケージのデフォルトレジストリとして構成されます。スコープの詳細については、「[パッケージの名前空間](packages-concepts.md#packages-concepts-package-namespaces)」および「[Scoped packages](https://docs.npmjs.com/cli/v10/using-npm/scope)」を参照してください。 1. **[Add]** (追加) を選択します。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **アクションで使用するパッケージ構成を指定するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. **ビルド**または**テスト**アクションで次のようなコードを追加します。 ``` action-name: Configuration: Packages: NpmConfiguration: PackageRegistries: - PackagesRepository: package-repository Scopes: - "@scope" ``` 詳細については、アクションの「[ビルドおよびテストアクション YAML](build-action-ref.md)」の `Packages` プロパティの説明を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # ワークフローアクションでの認証トークンの使用ワークフローアクションによって提供されるトークンを使用して、CodeCatalyst パッケージリポジトリで認証するようにパッケージマネージャーを手動で構成できます。CodeCatalyst では、このトークンをアクションで参照するための環境変数として利用できるようにします。 | 環境変数 | 値 | | --- | --- | | CATALYST\$1MACHINE\$1RESOURCE\$1NAME | 認証トークンのユーザー ID。 | | CATALYST\$1PACKAGES\$1AUTHORIZATION\$1TOKEN | 認可トークンの値。 | **注記** これらの環境変数は、認証トークンをエクスポートするようにアクションを構成している場合にのみ入力されることに注意してください。ワークフローアクションで認証トークンを使用するには、次の手順に従います。 ------ #### [ Visual ] **エクスポートされた認証トークンをアクションで使用するには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、パッケージリポジトリで構成する**ビルド**または**テスト**アクションを選択します。 1. **[パッケージ]** を選択します。 1. **[認証トークンをエクスポート]** をオンにします。 ------ #### [ YAML ] **エクスポートされた認証トークンをアクションで使用するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. **ビルド**または**テスト**アクションで次のようなコードを追加します。 ``` Actions: action-name: Packages: ExportAuthorizationToken: true ``` `$CATALYST_MACHINE_RESOURCE_NAME` および `$CATALYST_PACKAGES_AUTHORIZATION_TOKEN` 環境変数は YAML の `Steps` セクションで参照できます。詳細については、[例: CodeCatalyst で認証するように `pip` を手動で構成する](workflows-working-packages-ex.md#workflows-working-packages-pypi-token) を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 例: ワークフローのパッケージリポジトリ次の例は、ワークフロー定義ファイルでパッケージを参照する方法を示したものです。 **Topics** + [ ## 例: `NpmConfiguration` を使用したパッケージの定義 ](#workflows-working-packages-ex-basic) + [ ## 例: デフォルトレジストリのオーバーライド ](#workflows-working-packages-ex-overriding-registry) + [ ## 例: パッケージレジストリでのスコープのオーバーライド ](#workflows-working-packages-ex-overriding-scopes) + [ ## 例: CodeCatalyst で認証するように `pip` を手動で構成する ](#workflows-working-packages-pypi-token) ## 例: `NpmConfiguration` を使用したパッケージの定義次の例は、ワークフロー定義ファイルで `NpmConfiguration` を使用してパッケージを定義する方法を示したものです。 ``` Actions: Build: Identifier: aws/build-beta@v1 Configuration: Packages: NpmConfiguration: PackageRegistries: - PackagesRepository: main-repo - PackagesRepository: scoped-repo Scopes: - "@scope1" ``` この例では、npm クライアントを次のように構成します。 ``` default: main-repo @scope1: scoped-repo ``` この例では、2 つのリポジトリが定義されています。デフォルトレジストリはスコープなしで定義されているため、`main-repo` として設定されます。スコープ `@scope1` は `scoped-repo` の `PackageRegistries` で構成されています。 ## 例: デフォルトレジストリのオーバーライド次の例は、デフォルトレジストリをオーバーライドする方法を示したものです。 ``` NpmConfiguration: PackageRegistries: - PackagesRepository: my-repo-1 - PackagesRepository: my-repo-2 - PackagesRepository: my-repo-3 ``` この例では、npm クライアントを次のように構成します。 ``` default: my-repo-3 ``` 複数のデフォルトリポジトリを指定すると、最後のリポジトリが優先されます。この例では、一覧表示されている最後のリポジトリが `my-repo-3` であるため、npm は `my-repo-3` に接続します。これにより、リポジトリ `my-repo-1` と `my-repo-2` がオーバーライドされます。 ## 例: パッケージレジストリでのスコープのオーバーライド次の例は、パッケージレジストリでスコープをオーバーライドする方法を示したものです。 ``` NpmConfiguration: PackageRegistries: - PackagesRepository: my-default-repo - PackagesRepository: my-repo-1 Scopes: - "@scope1" - "@scope2" - PackagesRepository: my-repo-2 Scopes: - "@scope2" ``` この例では、npm クライアントを次のように構成します。 ``` default: my-default-repo @scope1: my-repo-1 @scope2: my-repo-2 ``` オーバーライドスコープを含めると、最後のリポジトリが優先されます。この例では、スコープ `@scope2` が最後に `PackageRegistries` で構成されたのは `my-repo-2` に対してです。これにより、`my-repo-1` に対して構成されているスコープ `@scope2` がオーバーライドされます。 ## 例: CodeCatalyst で認証するように `pip` を手動で構成する次の例は、ビルドアクションで CodeCatalyst 認証環境変数を参照する方法を示したものです。 ``` Actions: Build: Identifier: aws/build@v1.0.0 Configuration: Steps: - Run: pip config set global.index-url https://$CATALYST_MACHINE_RESOURCE_NAME:$CATALYST_PACKAGES_AUTHORIZATION_TOKEN@codecatalyst.aws/pypi/my-space/my-project/my-repo/simple/ Packages: ExportAuthorizationToken: true ``` # ワークフローを使用して Lambda 関数を呼び出すこのセクションでは、CodeCatalyst ワークフローを使用して AWS Lambda 関数を呼び出す方法について説明します。これを行うには、ワークフローに**AWS Lambda 呼び出し**アクションを追加する必要があります。**AWS Lambda 呼び出し**アクションは、指定された Lambda 関数を呼び出します。関数を呼び出すだけでなく、**AWS Lambda 呼び出し**アクションは Lambda 関数から受信したレスポンスペイロードの各最上位キーを[ワークフロー出力変数](workflows-working-with-variables.md)に変換します。その後、これらの変数は後続のワークフローアクションで参照できます。すべての最上位キーを変数に変換しない場合は、フィルターを使用して特定のキーを指定できます。詳細については、「[「AWS Lambda 呼び出し」アクション YAML](lam-invoke-action-ref.md)」の [ResponseFilters](lam-invoke-action-ref.md#lam.invoke.response.filters) プロパティの説明を参照してください。 **Topics** + [ ## このアクションを使用するタイミング ](#lam-invoke-action-when-to-use) + [ ## AWS Lambda 「呼び出し」アクションで使用されるランタイムイメージ ](#lam-invoke-action-runtime) + [ # 例: Lambda 関数を呼び出す ](lam-invoke-action-example-workflow.md) + [ # AWS Lambda 「呼び出し」アクションの追加 ](lam-invoke-action-add.md) + [ # 「AWS Lambda 呼び出し」変数 ](lam-invoke-action-variables.md) + [ # 「AWS Lambda 呼び出し」アクション YAML ](lam-invoke-action-ref.md) ## このアクションを使用するタイミング Lambda 関数にカプセル化され、Lambda 関数によって実行される機能をワークフローに追加したい場合は、このアクションを使用します。例えば、アプリケーションのビルドを開始する前に、ワークフローから Slack チャンネルに `Build started` 通知を送信したい場合です。この場合、ワークフローには、Lambda を呼び出して Slack 通知を送信する**AWS Lambda 呼び出し**アクションと、アプリケーションをビルドするための[ビルドアクション](build-add-action.md)が含まれます。別の例として、デプロイする前に、ワークフローでアプリケーションに対して脆弱性スキャンを実行したい場合があります。この場合、ビルドアクションを使用してアプリケーションをビルドし、**AWS Lambda 呼び出し**アクションで Lambda を呼び出して脆弱性をスキャンした後、デプロイアクションを使用してスキャンされたアプリケーションをデプロイします。 ## AWS Lambda 「呼び出し」アクションで使用されるランタイムイメージ **AWS Lambda 呼び出し**アクションは、[2022 年 11 月のイメージ](build-images.md#build.previous-image)で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。 # 例: Lambda 関数を呼び出す次のワークフローの例には、**AWS Lambda 呼び出し**アクションとデプロイアクションが含まれています。ワークフローは、デプロイが開始されたことを示す Slack 通知を送信し、 CloudFormation テンプレート AWS を使用してアプリケーションをにデプロイします。ワークフローは、連続して実行される次の構成要素で構成されます。 + **トリガー** – ソースリポジトリに変更をプッシュすると、このトリガーによってワークフローが自動的に開始されます。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + **AWS Lambda 呼び出し**アクション (`LambdaNotify`) – トリガー時に、このアクションは指定された AWS アカウントとリージョン (`my-aws-account` および `us-west-2`) で `Notify-Start` Lambda 関数を呼び出します。呼び出し時に、Lambda 関数はデプロイが開始されたことを示す Slack 通知を送信します。 + ** CloudFormation スタックのデプロイ**アクション (`Deploy`) – **AWS Lambda 呼び出し**アクションが完了すると、**スタックのデプロイ CloudFormation **アクションはテンプレート (`cfn-template.yml`) を実行してアプリケーションスタックをデプロイします。** CloudFormation スタックのデプロイ**アクションの詳細については、「」を参照してください[CloudFormation スタックのデプロイ](deploy-action-cfn.md)。 **注記** 次のワークフロー例は説明を目的としており、追加の設定なしでは機能しません。 **注記** 次の YAML コードでは、必要に応じて `Connections:` セクションを省略できます。これらのセクションを省略する場合は、環境の**デフォルトの IAM ロールフィールドに指定されたロール**に、**AWS Lambda スタックの呼び出し**および**デプロイ CloudFormation **アクションに必要なアクセス許可と信頼ポリシーが含まれていることを確認する必要があります。デフォルトの IAM ロールを使用して環境を設定する方法の詳細については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。スタックの**AWS Lambda 呼び出し**およびデプロイアクションに必要なアクセス許可と信頼ポリシーの詳細については、「」および「」の「 `Role`プロパティの説明」を参照してください[「AWS Lambda 呼び出し」アクション YAML](lam-invoke-action-ref.md)[CloudFormation 「スタックをデプロイ」アクション YAML](deploy-action-ref-cfn.md)。 ** CloudFormation ** ``` Name: codecatalyst-lamda-invoke-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: LambdaNotify: Identifier: aws/lambda-invoke@v1 Environment: Name: my-production-environment Connections: - Name: my-aws-account Role: codecatalyst-lambda-invoke-role Inputs: Sources: - WorkflowSource Configuration: Function: Notify-Start AWSRegion: us-west-2 Deploy: Identifier: aws/cfn-deploy@v1 Environment: Name: my-production-environment Connections: - Name: my-aws-account Role: codecatalyst-deploy-role Inputs: Sources: - WorkflowSource Configuration: name: my-application-stack region: us-west-2 role-arn: arn:aws:iam::111122223333:role/StackRole template: ./cfn-template.yml capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND ``` # AWS Lambda 「呼び出し」アクションの追加次の手順を使用して、**AWS Lambda 呼び出し**アクションをワークフローに追加します。 **前提条件** 開始する前に、 AWS Lambda 関数と関連する Lambda 実行ロールの準備が完了し、使用可能であることを確認します AWS。詳細については、「*AWS Lambda デベロッパーガイド*」の「[Lambda 実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)」を参照してください。 ------ #### [ Visual ] **ビジュアルエディタを使用してAWS Lambda 「呼び出し」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[AWS Lambda 呼び出し]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[AWS Lambda 呼び出し]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]**、**[設定]**、**[出力]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「AWS Lambda 呼び出し」アクション YAML](lam-invoke-action-ref.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用してAWS Lambda 「呼び出し」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[AWS Lambda 呼び出し]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[AWS Lambda 呼び出し]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「AWS Lambda 呼び出し」アクション YAML](lam-invoke-action-ref.md)」に記載されています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 「AWS Lambda 呼び出し」変数デフォルトでは、**AWS Lambda 呼び出し**アクションは Lambda レスポンスペイロードの最上位キーごとに 1 つの変数を生成します。例えば、レスポンスペイロードが次のような場合: ``` responsePayload = { "name": "Saanvi", "location": "Seattle", "department": { "company": "Amazon", "team": "AWS" } } ``` ...アクションは次の変数を生成します。 | キー | 値 | | --- | --- | | 名前 | Saanvi | | location | Seattle | | department | \$1"company": "Amazon", "team": "AWS"\$1 | **注記** `ResponseFilters` YAML プロパティを使用して、生成される変数を変更できます。詳細については、「[「AWS Lambda 呼び出し」アクション YAML](lam-invoke-action-ref.md)」の「[ResponseFilters](lam-invoke-action-ref.md#lam.invoke.response.filters)」を参照してください。実行時にAWS Lambda 「呼び出し」アクションによって生成および設定される変数は、*事前定義された変数*と呼ばれます。ワークフローでこの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください。 # 「AWS Lambda 呼び出し」アクション YAML **AWS Lambda 呼び出し**アクションの YAML 定義を次に示します。このアクションの使用方法については、「[ワークフローを使用して Lambda 関数を呼び出す](lam-invoke-action.md)」を参照してください。このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. LambdaInvoke\$1nn: Identifier: aws/lambda-invoke@v1 DependsOn: - dependent-action Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - request-payload Variables: - Name: variable-name-1 Value: variable-value-1 - Name: variable-name-2 Value: variable-value-2 Environment: Name: environment-name Connections: - Name: account-connection-name Role: iam-role-name Configuration: Function: my-function|function-arn AWSRegion: us-west-2 # Specify RequestPayload or RequestPayloadFile, but not both. RequestPayload: '{"firstname": "Li", lastname: "Jean", "company": "ExampleCo", "team": "Development"}' RequestPayloadFile: my/request-payload.json ContinueOnError: true|false LogType: Tail|None ResponseFilters: '{"name": ".name", "company": ".department.company"}' Outputs: Artifacts: - Name: lambda_artifacts Files: - "lambda-response.json" ``` ## LambdaInvoke (必須) アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。デフォルト: `Lambda_Invoke_Action_Workflow_nn`。対応する UI: [設定] タブ/**[アクション名]** ## Identifier (*LambdaInvoke*/**Identifier**) (必須) アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。デフォルト: `aws/lambda-invoke@v1`。対応する UI: ワークフロー図/LambdaInvoke\$1nn/**aws/lambda-invoke@v1** ラベル ## DependsOn (*LambdaInvoke*/**DependsOn**) (オプション) このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。対応する UI: [入力] タブ/**[依存 - オプション]** ## Compute (*LambdaInvoke*/**Compute**) (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。対応する UI: *[なし]* ## Type (*LambdaInvoke*/Compute/**Type**) ([Compute](#lam.invoke.computename) が含まれている場合は必須) コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。 + **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ) アクション実行時の柔軟性を目的として最適化されています。 + **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ) アクションの起動速度を最適化しました。コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。対応する UI: [設定] タブ/**[コンピューティングタイプ]** ## Fleet (*LambdaInvoke*/Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。対応する UI: [設定] タブ/**[コンピューティングフリート]** ## Timeout (*LambdaInvoke*/**Timeout**) (必須) CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。対応する UI: [設定] タブ/**[タイムアウト - オプション]** ## Inputs (*LambdaInvoke*/**Inputs**) (必須) この `Inputs` セクションは、ワークフローの実行中に**AWS Lambda 呼び出し**アクションに必要なデータを定義します。 **注記** **AWS Lambda 呼び出し**アクションごとに 1 つの入力 (ソースまたはアーティファクト) のみが許可されます。変数はこの合計にはカウントされません。対応する UI: **[入力] タブ** ## Sources (*LambdaInvoke*/Inputs/**Sources**) ([RequestPayloadFile](#lam.invoke.request.payload.file) が指定されている場合は必須) リクエストペイロード JSON ファイルを **AWS Lambda 呼び出し**アクションに渡したい場合で、このペイロードファイルがソースリポジトリに格納されている場合は、そのソースリポジトリのラベルを指定します。現在サポートされているラベルは、`WorkflowSource` のみです。リクエストペイロードファイルがソースリポジトリに含まれていない場合、別のアクションによって生成されたアーティファクトに存在する必要があります。ペイロードの詳細については、「[RequestPayloadFile](#lam.invoke.request.payload.file)」を参照してください。 **注記** ペイロードファイルを指定する代わりに、`RequestPayload` プロパティを使用してペイロードの JSON コードをアクションに直接追加できます。詳細については、「[RequestPayload](#lam.invoke.request.payload)」を参照してください。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。対応する UI: [入力] タブ/**[ソース - オプション]** ## Artifacts - input (*LambdaInvoke*/Inputs/**Artifacts**) ([RequestPayloadFile](#lam.invoke.request.payload.file) が指定されている場合は必須) リクエストペイロード JSON ファイルを**AWS Lambda 呼び出し**アクションに渡したい場合で、このペイロードファイルが前のアクションの[出力アーティファクト](build-action-ref.md#build.outputs.artifacts)に含まれている場合は、ここでそのアーティファクトを指定します。ペイロードの詳細については、「[RequestPayloadFile](#lam.invoke.request.payload.file)」を参照してください。 **注記** ペイロードファイルを指定する代わりに、`RequestPayload` プロパティを使用してペイロードの JSON コードをアクションに直接追加できます。詳細については、「[RequestPayload](#lam.invoke.request.payload)」を参照してください。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [設定] タブ/**[アーティファクト - オプション]** ## Variables - input (*LambdaInvoke*/Inputs/**Variables**) (オプション) アクションで使用できるようにしたい入力変数を定義する名前と値のペアのシーケンスを指定します。変数名に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、変数名で特殊文字とスペースを有効にすることはできません。変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。対応する UI: [入力] タブ/**[変数 - オプション]** ## Environment (*LambdaInvoke*/**Environment**) (必須) アクションで使用する CodeCatalyst 環境を指定します。アクションは、選択した環境で指定された AWS アカウントおよびオプションの Amazon VPC に接続します。アクションは、環境で指定されたデフォルトの IAM ロールを使用してに接続し AWS アカウント、[Amazon VPC 接続](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html)で指定された IAM ロールを使用して Amazon VPC に接続します。 **注記** デフォルトの IAM ロールにアクションに必要なアクセス許可がない場合は、別のロールを使用するようにアクションを設定できます。詳細については、「[アクションの IAM ロールの変更](deploy-environments-switch-role.md)」を参照してください。環境タグ付けの詳細については、「[AWS アカウントと VPCs へのデプロイ](deploy-environments.md)」と「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: [設定] タブ/**[環境]** ## Name (*LambdaInvoke*/Environment/**Name**) ([Environment](#lam.invoke.environment) が含まれている場合は必須) アクションに関連付ける既存の環境の名前を指定します。対応する UI: [設定] タブ/**[環境]** ## Connections (*LambdaInvoke*/Environment/**Connections**) (新しいバージョンのアクションでは任意。古いバージョンでは必須) アクションに関連付けるアカウント接続を指定します。`Environment` で最大 1 つのアカウント接続を指定できます。アカウント接続を指定しない場合: + アクションは、CodeCatalyst コンソールの環境で指定された AWS アカウント接続とデフォルトの IAM ロールを使用します。アカウント接続とデフォルトの IAM ロールを環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。 + デフォルトの IAM ロールには、アクションに必要なポリシーとアクセス許可が含まれている必要があります。これらのポリシーとアクセス許可を確認するには、アクションの YAML 定義ドキュメントの **[ロール]** プロパティの説明を参照してください。アカウント接続の詳細については、「[接続された AWS リソースへのアクセスを許可する AWS アカウント](ipa-connect-account.md)」を参照してください。アカウント接続を環境に追加する方法については、「[環境を作成する](deploy-environments-creating-environment.md)」を参照してください。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Name (*LambdaInvoke*/Environment/Connections/**Name**) ([Connections](#lam.invoke.environment.connections) が含まれている場合は必須) アカウント接続の名前を指定します。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[AWS アカウント接続]** ## Role (*LambdaInvoke*/Environment/Connections/**Role**) ([Connections](#lam.invoke.environment.connections) が含まれている場合は必須) **AWS Lambda 呼び出し**アクションが Lambda 関数へのアクセス AWS と呼び出しに使用する IAM ロールの名前を指定します。[ロールを CodeCatalyst スペースに追加](ipa-connect-account-addroles.md)し、ロールに次のポリシーが含まれていることを確認します。 IAM ロールを指定しない場合、アクションは CodeCatalyst コンソールの [[環境]](deploy-environments.md) に記載されているデフォルトの IAM ロールを使用します。環境でデフォルトのロールを使用する場合は、次のポリシーがあることを確認してください。 + 以下のアクセス許可ポリシー: **警告** アクセス許可は、次のポリシーに示すアクセス許可に制限します。範囲の広いアクセス許可を持つロールを使用すると、セキュリティリスクが発生する可能性があります。 + 次のカスタム信頼ポリシー: **注記** 必要に応じて、このアクションで `CodeCatalystWorkflowDevelopmentRole-spaceName` ロールを使用できます。このロールの詳細については、「[アカウントとスペース用の **CodeCatalystWorkflowDevelopmentRole-*spaceName*** ロールを作成する](ipa-iam-roles.md#ipa-iam-roles-service-create)」を参照してください。`CodeCatalystWorkflowDevelopmentRole-spaceName` ロールにはフルアクセス許可があり、セキュリティ上のリスクをもたらす可能性があることを理解してください。このロールは、セキュリティが懸念されないチュートリアルやシナリオでのみ使用することをお勧めします。対応する UI: アクションのバージョンに応じて、次のいずれか。 + (新しいバージョン) [設定] タブ/[環境]/[*my-environment* の内容]/3 つのドットメニュー/**[ロールを切り替える]** + (旧バージョン) [設定] タブ/「環境/アカウント/ロール」/**[ロール]** ## Configuration (*LambdaInvoke*/**Configuration**) (必須) アクションの設定プロパティを定義できるセクション。対応する UI: **[設定]** タブ ## Function (*LambdaInvoke*/Configuration/**Function**) (必須) このアクションが呼び出す AWS Lambda 関数を指定します。関数名または Amazon リソースネーム (ARN) を指定できます。関数名または ARN は、Lambda コンソールで確認できます。 **注記** Lambda 関数が存在する AWS アカウントは、で指定されたアカウントとは異なる場合があります`Connections:`。対応する UI: [設定] タブ/**[関数]** ## AWSRegion (*LambdaInvoke*/Configuration/**AWSRegion**) (必須) AWS Lambda 関数が存在する AWS リージョンを指定します。リージョンコードの一覧については、「*AWS 全般のリファレンス*」の「[Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints)」を参照してください。対応する UI: [設定] タブ/**[送信先バケット - オプション]** ## RequestPayload (*LambdaInvoke*/Configuration/**RequestPayload**) (オプション) リクエストペイロードを **AWS Lambda 呼び出し**アクションに渡す場合は、JSON 形式でリクエストペイロードをここで指定します。リクエストペイロードの例: ``` '{ "key": "value" }' ``` Lambda 関数にリクエストペイロードを渡さない場合は、このプロパティを省略します。 **注記** `RequestPayload` または `RequestPayloadFile` を指定できます。両方を指定することはできません。リクエストペイロードの詳細については、「*AWS Lambda API リファレンス*」の「[Invoke](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)」トピックを参照してください。対応する UI: [設定] タブ/**[リクエストペイロード - オプション]** ## RequestPayloadFile (*LambdaInvoke*/Configuration/**RequestPayloadFile**) (オプション) リクエストペイロードを **AWS Lambda 呼び出し**アクションに渡す場合は、ここでこのリクエストペイロードファイルのパスを指定します。ファイルは JSON 形式である必要があります。リクエストペイロードファイルは、ソースリポジトリまたは前のアクションのアーティファクトに置くことができます。ファイルパスは、ソースリポジトリまたはアーティファクトのルートを基準としています。 Lambda 関数にリクエストペイロードを渡さない場合は、このプロパティを省略します。 **注記** `RequestPayload` または `RequestPayloadFile` を指定できます。両方を指定することはできません。リクエストペイロードファイルの詳細については、「*AWS Lambda API リファレンス*」の「[Invoke](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)」トピックを参照してください。対応する UI: [設定] タブ/**[リクエストペイロードファイル - オプション]** ## ContinueOnError (*LambdaInvoke*/Configuration/**RequestPayloadFile**) (オプション) 呼び出した AWS Lambda 関数が失敗した場合でも、**AWS Lambda 呼び出し**アクションを成功としてマークするかどうかを指定します。Lambda が失敗したにもかかわらず、ワークフロー内の後続のアクションを開始できるように、このプロパティを `true` に設定することを検討してください。デフォルトでは、Lambda 関数が失敗した場合、アクションは失敗します (ビジュアルエディタでは「off」、YAML エディタでは「`false`」)。対応する UI: [設定] タブ/**[エラー発生時に続行]** ## LogType (*LambdaInvoke*/Configuration/**LogType**) (オプション) 呼び出し後に Lambda 関数からのレスポンスにエラーログを含めるかどうかを指定します。このログは、CodeCatalyst コンソールの **Lambda 呼び出し**アクションの **[ログ]** タブで表示できます。可能な値は以下のとおりです。 + `Tail` – ログを返す + `None` – ログを返さないデフォルトでは **[Tail]** に設定されています。ログタイプの詳細については、「*AWS Lambda API リファレンス*」の「[Invoke](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)」トピックを参照してください。ログの表示の詳細については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。対応する UI: [設定] タブ/**[ログタイプ]** ## ResponseFilters (*LambdaInvoke*/Configuration/**ResponseFilters**) (オプション) Lambda レスポンスペイロードのどのキーを出力変数に変換するかを指定します。その後、ワークフロー内の後続のアクションで出力変数を参照できます。CodeCatalyst における変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。例えば、レスポンスペイロードが次のような場合: ``` responsePayload = { "name": "Saanvi", "location": "Seattle", "department": { "company": "Amazon", "team": "AWS" } } ``` ...そして、レスポンスフィルターは次のような場合: ``` Configuration: ... ResponseFilters: '{"name": ".name", "company": ".department.company"}' ``` ...アクションは次の出力変数を生成します。 | キー | 値 | | --- | --- | | 名前 | Saanvi | | company | Amazon | その後、後続のアクションで `name` 変数と `company` 変数を参照できます。 `ResponseFilters` でキーを指定しない場合、アクションは Lambda レスポンスの各最上位キーを出力変数に変換します。詳細については、「[「AWS Lambda 呼び出し」変数](lam-invoke-action-variables.md)」を参照してください。レスポンスフィルターを使用して、生成された出力変数を実際に使用するもののみに制限することを検討してください。対応する UI: [設定] タブ/**[レスポンスフィルター - オプション]** ## Outputs (*LambdaInvoke*/**Outputs**) (オプション) ワークフローの実行中にアクションによって出力されるデータを定義します。対応する UI: **[出力]** タブ ## Artifacts (*LambdaInvoke*/Outputs/**Artifacts**) (オプション) アクションによって生成されたアーティファクトを指定します。このアーティファクトは、他のアクションの入力として参照できます。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [出力] タブ/[アーティファクト]/**[ビルドアーティファクト名]** ## Name (*LambdaInvoke*/Outputs/Artifacts/**Name**) (オプション) Lambda 関数によって返される Lambda レスポンスペイロードを含むアーティファクトの名前を指定します。デフォルト値は `lambda_artifacts` です。アーティファクトを指定しない場合、Lambda レスポンスペイロードをアクションのログで表示できます。これは、CodeCatalyst コンソールのアクションの **[ログ]** タブにあります。ログの表示の詳細については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。対応する UI: [出力] タブ/[アーティファクト]/**[ビルドアーティファクト名]** ## Files (*LambdaInvoke*/Outputs/Artifacts/**Files**) (オプション) アーティファクトに含めるファイルを指定します。Lambda レスポンスペイロードファイルを含めるように `lambda-response.json` を指定する必要があります。対応する UI: [出力] タブ/[アーティファクト]/**[ビルドで生成されるファイル]** # Amazon ECS タスク定義の変更このセクションでは、CodeCatalyst ワークフローを使用して Amazon Elastic Container Service (Amazon ECS) [タスク定義ファイルの](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions) `image` フィールドを更新する方法について説明します。これを行うには、「**Amazon ECS タスク定義のレンダリング**」アクションをワークフローに追加する必要があります。このアクションによって、タスク定義ファイルの image フィールドが、実行時にワークフローで指定された Docker イメージ名で更新されます。 **注記** このアクションを使用して、タスク定義の `environment` フィールドを環境変数で更新することもできます。 **Topics** + [ ## このアクションを使用する場合 ](#render-ecs-action-when-to-use) + [ ## 「Amazon ECS タスク定義のレンダリング」アクションの仕組み ](#render-ecs-action-how-it-works) + [ ## 「Amazon ECS タスク定義のレンダリング」アクションで使用されるランタイムイメージ ](#render-ecs-action-runtime) + [ # 例: Amazon ECS taskdef を変更する ](render-ecs-action-example-workflow.md) + [ # 「Amazon ECS タスク定義のレンダリング」アクションの追加 ](render-ecs-action-add.md) + [ # 更新されたタスク定義ファイルの表示 ](render-ecs-action-view.md) + [ # 「Amazon ECS タスク定義のレンダリング」の変数 ](render-ecs-action-variables.md) + [ # 「Amazon ECS タスク定義のレンダリング」アクション YAML ](render-ecs-action-ref.md) ## このアクションを使用する場合このアクションは、ワークフローで Docker イメージをビルドして、動的コンテンツ (コミット ID やタイムスタンプなど) でタグ付けする場合に使用します。タスク定義ファイルに常に同じイメージ値が含まれる場合は、このアクションを使用しないでください。その場合には、イメージの名前をタスク定義ファイルに手動で入力できます。 ## 「Amazon ECS タスク定義のレンダリング」アクションの仕組み **Amazon ECS タスク定義のレンダリング**アクションは、ワークフローの**ビルド**アクションと **Amazon ECS へのデプロイ**アクションで使用する必要があります。これらのアクションは連携して、次のように機能します。 1. **ビルド**アクションでは、Docker イメージをビルドし、名前、コミット ID、タイムスタンプ、その他の動的コンテンツでタグ付けします。例えば、ビルドアクションは次のようになります。 ``` MyECSWorkflow Actions: BuildAction: Identifier: aws/build@v1 ... Configuration: Steps: # Build, tag, and push the Docker image... - Run: docker build -t MyDockerImage:${WorkflowSource.CommitId} . ... ``` 上記のコードでは、アクションの実行時に `docker build -t` ディレクティブが Docker イメージをビルドし、コミット ID でタグ付けします。生成されたイメージ名は次のようになります。 `MyDockerImage:a37bd7e` 1. **Amazon ECS タスク定義のレンダリング**アクションは、次のように、動的に生成されたイメージ名 `MyDockerImage:a37bd7e` をタスク定義ファイルに追加します。 ``` { "executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role", "containerDefinitions": [ { "name": "codecatalyst-ecs-container", "image": MyDockerImage:a37bd7e, "essential": true, ... "portMappings": [ { "hostPort": 80, "protocol": "tcp", "containerPort": 80 } ] } ], ... } ``` 必要に応じて、次のように、**Amazon ECS タスク定義のレンダリング**アクションでタスク定義に環境変数を追加することもできます。 ``` { "executionRoleArn": "arn:aws:iam::account_ID:role/codecatalyst-ecs-task-execution-role", "containerDefinitions": [ { "name": "codecatalyst-ecs-container", "image": MyDockerImage:a37bd7e, ... "environment": [ { name": "ECS_LOGLEVEL", value": "info" } ] } ], ... } ``` 環境変数の詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[環境変数の指定](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/taskdef-envfiles.html)」を参照してください。 1. **Amazon ECS へのデプロイ**アクションは、更新されたタスク定義ファイルを Amazon ECS に登録します。更新されたタスク定義ファイルを登録すると、新しいイメージ `MyDockerImage:a37bd7e` が Amazon ECS にデプロイされます。 ## 「Amazon ECS タスク定義のレンダリング」アクションで使用されるランタイムイメージ **Amazon ECS タスク定義のレンダリング**アクションは、[2022 年 11 月のイメージ](build-images.md#build.previous-image)で実行されます。詳細については、「[アクティブなイメージ](build-images.md#build-curated-images)」を参照してください。 # 例: Amazon ECS taskdef を変更する以下は、**Amazon ECS タスク定義のレンダリング**アクションとビルドおよびデプロイアクションを含む、完全なワークフローの例です。このワークフローの目的は、Docker イメージをビルドして Amazon ECS クラスターにデプロイすることです。このワークフローは、連続して実行される次の構成要素で構成されます。 + **トリガー** – ソースリポジトリに変更をプッシュすると、このトリガーによってワークフローが自動的に開始されます。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。 + **ビルド**アクション (`BuildDocker`) – トリガーされると、アクションは Dockerfile を使用して Docker イメージをビルドし、コミット ID でタグ付けして、イメージを Amazon ECR にプッシュします。ビルドアクションの詳細については、「[ワークフローを使用したビルド](build-workflow-actions.md)」を参照してください。 + **Amazon ECS タスク定義のレンダリング**アクション (`RenderTaskDef`) – ビルドアクションが完了すると、このアクションはソースリポジトリのルートにある既存の `taskdef.json` を、正しいコミット ID を含む `image` フィールド値で更新します。更新されたファイルが新しいファイル名 (`task-definition-random-string.json`) で保存され、このファイルを含む出力アーティファクトが作成されます。レンダリングアクションは `task-definition` という変数も生成し、それを新しいタスク定義ファイルの名前に設定します。デプロイアクションでは、次のようなアーティファクトと変数が使用されます。 + **Amazon ECS へのデプロイ**アクション (`DeployToECS`) – **Amazon ECS タスク定義のレンダリング**アクションが完了すると、**Amazon ECS にデプロイ**アクションは、レンダリングアクション (`TaskDefArtifact`) によって生成された出力アーティファクトを探し、その中にある `task-definition-random-string.json` ファイルを見つけて、Amazon ECS サービスに登録します。次に、Amazon ECS サービスは、`task-definition-random-string.json` ファイルの手順に従って、Amazon ECS クラスター内で Amazon ECS タスクと関連する Docker イメージコンテナを実行します。 ``` Name: codecatalyst-ecs-workflow SchemaVersion: 1.0 Triggers: - Type: PUSH Branches: - main Actions: BuildDocker: Identifier: aws/build@v1 Environment: Name: codecatalyst-ecs-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-ecs-build-role Inputs: Variables: - Name: REPOSITORY_URI Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo - Name: IMAGE_TAG Value: ${WorkflowSource.CommitId} Configuration: Steps: #pre_build: - Run: echo Logging in to Amazon ECR... - Run: aws --version - Run: aws ecr get-login-password --region us-east-2 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-2.amazonaws.com #build: - Run: echo Build started on `date` - Run: echo Building the Docker image... - Run: docker build -t $REPOSITORY_URI:latest . - Run: docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG #post_build: - Run: echo Build completed on `date` - Run: echo Pushing the Docker images... - Run: docker push $REPOSITORY_URI:latest - Run: docker push $REPOSITORY_URI:$IMAGE_TAG RenderTaskDef: DependsOn: - BuildDocker Identifier: aws/ecs-render-task-definition@v1 Inputs: Variables: - Name: REPOSITORY_URI Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo - Name: IMAGE_TAG Value: ${WorkflowSource.CommitId} Configuration: task-definition: taskdef.json container-definition-name: codecatalyst-ecs-container image: $REPOSITORY_URI:$IMAGE_TAG # The output artifact contains the updated task definition file. # The new file is prefixed with 'task-definition'. # The output variable is set to the name of the updated task definition file. Outputs: Artifacts: - Name: TaskDefArtifact Files: - "task-definition*" Variables: - task-definition DeployToECS: Identifier: aws/ecs-deploy@v1 Environment: Name: codecatalyst-ecs-environment Connections: - Name: codecatalyst-account-connection Role: codecatalyst-ecs-deploy-role #Input artifact contains the updated task definition file. Inputs: Sources: [] Artifacts: - TaskDefArtifact Configuration: region: us-east-2 cluster: codecatalyst-ecs-cluster service: codecatalyst-ecs-service task-definition: ${RenderTaskDef.task-definition} ``` # 「Amazon ECS タスク定義のレンダリング」アクションの追加次の手順を使用して、「**Amazon ECS タスク定義のレンダリング**」アクションをワークフローに追加します。 **前提条件** 開始する前に、Docker イメージを動的に生成するビルドアクションを含むワークフローがあることを確認してください。詳細については、前述の[ワークフローの例](render-ecs-action-example-workflow.md)を参照してください。 ------ #### [ Visual ] **ビジュアルエディタを使用して「Amazon ECS タスク定義のレンダリング」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[Amazon ECS タスク定義のレンダリング]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[Amazon ECS タスク定義のレンダリング]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. **[入力]** タブと **[設定]** タブで、必要に応じてフィールドに入力します。各フィールドの説明については、「[「Amazon ECS タスク定義のレンダリング」アクション YAML](render-ecs-action-ref.md)」を参照してください。このリファレンスでは、各フィールド (および対応する YAML プロパティ値) について、YAML エディタとビジュアルエディタの両方で表示される詳細情報を提供しています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **YAML エディタを使用して「Amazon ECS タスク定義のレンダリング」アクションを追加するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 左上で **[\$1 アクション]** を選択してアクションカタログを開きます。 1. ドロップダウンリストから、**[Amazon CodeCatalyst]** を選択します。 1. **[Amazon ECS タスク定義のレンダリング]** アクションを検索し、次のいずれかを実行します。 + プラス記号 (**＋**) を選択してワークフロー図にアクションを追加し、設定ペインを開きます。または + **[Amazon ECS タスク定義のレンダリング]** を選択します。アクションの詳細ダイアログボックスが表示されます。このダイアログボックスで、次の操作を行います。 + (任意) **[ソースを表示]** を選択して、[アクションのソースコードを表示します](workflows-view-source.md#workflows-view-source.title)。 + **[ワークフローに追加]** を選択して、ワークフロー図にアクションを追加し、設定ペインを開きます。 1. 必要に応じて、YAML コードのプロパティを変更します。使用可能な各プロパティの説明は、「[「Amazon ECS タスク定義のレンダリング」アクション YAML](render-ecs-action-ref.md)」に記載されています。 1. (オプション) **[検証]** を選択して、コミットする前にワークフローの YAML コードを検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ **次の手順** レンダリングアクションを追加したら、「[ワークフローを使用した Amazon ECS へのデプロイ](deploy-action-ecs.md)」の指示に従って、「**Amazon ECS にデプロイ**」アクションをワークフローに追加します。デプロイアクションを追加するときに、以下を実行します。 1. デプロイアクションの**[入力]** タブの **[アーティファクト - オプション]** で、レンダリングアクションによって生成されたアーティファクトを選択します。これには更新されたタスク定義ファイルが含まれています。アーティファクトの詳細については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。 1. デプロイアクションの **[設定]** タブの **[タスク定義]** フィールドで、アクション変数 `${action-name.task-definition}` を指定します。ここで、*action-name* はレンダリングアクションの名前 (例えば `RenderTaskDef`) です。レンダリングアクションは、この変数をタスク定義ファイルの新しい名前に設定します。変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。デプロイアクションの設定方法の詳細については、前述の[ワークフローの例](render-ecs-action-example-workflow.md)を参照してください。 # 更新されたタスク定義ファイルの表示更新されたタスク定義ファイルの名前と内容を表示できます。 ****Amazon ECS タスク定義のレンダリング**アクションで処理された後、更新されたタスク定義ファイルの名前を表示する。** 1. 完了したレンダリングアクションを含む実行を見つけます。 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. 完了したレンダリングアクションを含む実行を選択します。 1. ワークフロー図で、レンダリングアクションを選択します。 1. **[出力]** を選択します。 1. **[変数]** を選択します。 1. タスク定義ファイル名が表示されます。`task-definition--259-0a2r7gxlTF5X-.json` のようになります。 **更新されたタスク定義ファイルの内容を表示するには** 1. 完了したレンダリングアクションを含む実行を見つけます。 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. 完了したレンダリングアクションを含む実行を選択します。 1. ワークフロー実行で、上部の **[ビジュアル]** と **[YAML]** の横にある **[ワークフロー出力]** を選択します。 1. **[アーティファクト]** セクションで、更新されたタスク定義ファイルを含むアーティファクトの横にある **[ダウンロード]** を選択します。このアーティファクトの **[次によって生成済み:]** 列は、は、レンダリングアクションの名前に設定されます。 1. .zip ファイルを開き、タスク定義の .json ファイルを表示します。 # 「Amazon ECS タスク定義のレンダリング」の変数 **Amazon ECS タスク定義のレンダリング**アクションは、実行時に次の変数を生成して設定します。これらは*事前定義済み変数*と呼ばれます。ワークフローでこれらの変数を参照する方法については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください | キー | 値 | | --- | --- | | タスク定義 | **Amazon ECS タスク定義のレンダリング**アクションによって更新されたタスク定義ファイルに付けられた名前。バケット名は `task-definition-random-string.json` 形式に従います。例: `task-definition--259-0a2r7gxlTF5Xr.json` | # 「Amazon ECS タスク定義のレンダリング」アクション YAML 以下は、**Amazon ECS タスク定義のレンダリング**アクションの YAML 定義です。このアクションの使用方法については、「[Amazon ECS タスク定義の変更](render-ecs-action.md)」を参照してください。このアクション定義は、より広範なワークフロー定義ファイル内のセクションとして存在します。ファイルの詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**[Ctrl\$1F]** を使用します。要素は、関連付けられた YAML プロパティとともに一覧表示されます。 ``` # The workflow definition starts here. # See 最上位プロパティ for details. Name: MyWorkflow SchemaVersion: 1.0 Actions: # The action definition starts here. ECSRenderTaskDefinition\$1nn: Identifier: aws/ecs-render-task-definition@v1 DependsOn: - build-action Compute: Type: EC2 | Lambda Fleet: fleet-name Timeout: timeout-minutes Inputs: # Specify a source or an artifact, but not both. Sources: - source-name-1 Artifacts: - task-definition-artifact Variables: - Name: variable-name-1 Value: variable-value-1 - Name: variable-name-2 Value: variable-value-2 Configuration task-definition: task-definition-path container-definition-name: container-definition-name image: docker-image-name environment-variables: - variable-name-1=variable-value-1 - variable-name-2=variable-value-2 Outputs: Artifacts: - Name: TaskDefArtifact Files: "task-definition*" Variables: - task-definition ``` ## ECSRenderTaskDefinition (必須) アクションの名前を指定します。すべてのアクション名は、ワークフロー内で一意である必要があります。アクション名で使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、アクション名の特殊文字とスペースを有効にすることはできません。デフォルト: `ECSRenderTaskDefinition_nn`。対応する UI: [設定] タブ/**[アクション名]** ## Identifier (*ECSRenderTaskDefinition*/**Identifier**) (必須) アクションを識別します。バージョンを変更したい場合でない限り、このプロパティを変更しないでください。詳細については、「[使用するアクションバージョンの指定](workflows-action-versions.md)」を参照してください。デフォルト: `aws/ecs-render-task-definition@v1`。対応する UI: ワークフロー図/ECSRenderTaskDefinition\$1nn/**aws/ecs-render-task-definition@v1** ラベル ## DependsOn (*ECSRenderTaskDefinition*/**DependsOn**) (オプション) このアクションを実行するために正常に実行する必要があるアクション、アクショングループ、またはゲートを指定します。「DependsOn」機能の詳細については、「[アクションの順序付け](workflows-depends-on.md)」を参照してください。対応する UI: [入力] タブ/**[依存 - オプション]** ## Compute (*ECSRenderTaskDefinition*/**Compute**) (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。対応する UI: *[なし]* ## Type (*ECSRenderTaskDefinition*/Compute/**Type**) ([Compute](#render.ecs.computename) が含まれている場合は必須) コンピューティングエンジンのタイプです。次のいずれかの値を使用できます。 + **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ) アクション実行時の柔軟性を目的として最適化されています。 + **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ) アクションの起動速度を最適化しました。コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。対応する UI: [設定] タブ/**[コンピューティングタイプ]** ## Fleet (*ECSRenderTaskDefinition*/Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。対応する UI: [設定] タブ/**[コンピューティングフリート]** ## Timeout (*ECSRenderTaskDefinition*/**Timeout**) (オプション) CodeCatalyst がアクションを終了するまでにアクションを実行できる時間を分単位 (YAML エディタ) または時間分単位 (ビジュアルエディタ) で指定します。最小値は 5 分で、最大値は [CodeCatalyst のワークフローのクォータ](workflows-quotas.md) で記述されています。デフォルトのタイムアウトは、最大タイムアウトと同じです。対応する UI: [設定] タブ/**[タイムアウト - オプション]** ## Inputs (*ECSRenderTaskDefinition*/**Inputs**) (オプション) `Inputs` セクションでは、ワークフローの実行中に `ECSRenderTaskDefinition` に必要なデータを定義します。 **注記** **Amazon ECS タスク定義のレンダリング**アクションごとに 1 つの入力 (ソースまたはアーティファクト) のみが許可されます。変数はこの合計にはカウントされません。対応する UI: **入力**タブ ## Sources (*ECSRenderTaskDefinition*/Inputs/**Sources**) (タスク定義ファイルがソースリポジトリに保存されている場合は必須) タスク定義ファイルがソースリポジトリに保存されている場合は、そのソースリポジトリのラベルを指定します。現在サポートされているラベルは、`WorkflowSource` のみです。タスク定義ファイルがソースリポジトリに含まれていない場合は、別のアクションによって生成されたアーティファクトに存在する必要があります。 sources の詳細については、「[ワークフローへのソースリポジトリの接続](workflows-sources.md)」を参照してください。対応する UI: 入力タブ/**[ソース - オプション]** ## Artifacts - input (*ECSRenderTaskDefinition*/Inputs/**Artifacts**) (タスク定義ファイルが前のアクションの[出力アーティファクト](workflows-working-artifacts-output.md)に保存されている場合は必須) デプロイするタスク定義ファイルが以前のアクションによって生成されたアーティファクトに含まれている場合は、ここでそのアーティファクトを指定します。タスク定義ファイルがアーティファクトに含まれていない場合は、ソースリポジトリに存在する必要があります。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [設定] タブ/**[アーティファクト - オプション]** ## Variables - input (*ECSRenderTaskDefinition*/Inputs/**Variables**) (必須) アクションで使用する入力変数を定義する名前と値のペアのシーケンスを指定します。変数名に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、変数名で特殊文字とスペースを有効にすることはできません。変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。対応する UI: [入力] タブ/**[変数 - オプション]** ## Configuration (*ECSRenderTaskDefinition*/**Configuration**) (必須) アクションの設定プロパティを定義できるセクション。対応する UI: **[設定]** タブ ## task-definition (*ECSRenderTaskDefinition*/Configuration/**task-definition**) (必須) 既存のタスク定義ファイルへのパスを指定します。ファイルがソースリポジトリに存在する場合、パスはソースリポジトリのルートフォルダに相対します。ファイルが以前のワークフローアクションのアーティファクトに存在する場合、パスはアーティファクトルートフォルダを基準としています。タスク定義ファイルの詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[タスク定義](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html#welcome-task-definitions)」を参照してください。対応する UI: [設定] タブ/**[タスク定義]** ## container-definition-name (*ECSRenderTaskDefinition*/Configuration/**container-definition-name**) (必須) Docker イメージを実行するコンテナの名前を指定します。この名前はタスク定義ファイルの `containerDefinitions`、`name`フィールドにあります。詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[名前](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_name)」を参照してください。対応する UI: [設定] タブ/**[コンテナ名]** ## image (*ECSRenderTaskDefinition*/Configuration/**image**) (必須) **Amazon ECS タスク定義のレンダリング**アクションでタスク定義ファイルに追加する Docker イメージの名前を指定します。アクションは、タスク定義ファイルの `containerDefinitions`、`image`フィールドにこの名前を追加します。値が `image` フィールドに既に存在する場合、アクションは値を上書きします。イメージ名には変数を含めることができます。例: `MyDockerImage:${WorkflowSource.CommitId}` を指定すると、アクションによって `MyDockerImage:commit-id` がタスク定義ファイルに追加されます。ここで、*commit-id* はワークフローによって実行時に生成されるコミット ID です。 `my-ecr-repo/image-repo:$(date +%m-%d-%y-%H-%m-%s)` を指定すると、アクションによって、*my-ecr-repo*/image-repo:*date \$1%m-%d-%y-%H-%m-%s* がタスク定義ファイルに追加されます。ここで、*my-ecr-repo* は Amazon Elastic Container Registry (ECR) の URI であり、*date \$1%m-%d-%y-%H-%m-%s* はワークフローによって実行時に生成される `month-day-year-hour-minute-second` 形式のタイムスタンプです。 `image` の詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[イメージ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_image)」を参照してください。変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。対応する UI: [設定] タブ/**[イメージ名]** ## environment-variables (*ECSRenderTaskDefinition*/Configuration/**environment-variables**) (必須) **Amazon ECS タスク定義のレンダリング**アクションでタスク定義ファイルに追加する環境変数を指定します。アクションは、タスク定義ファイルの `containerDefinitions`、`environment`フィールドに変数を追加します。変数がファイル内に既に存在する場合、アクションは既存の変数の値を上書きし、新しい変数を追加します。Amazon ECS の環境変数の詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[環境変数の指定](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/taskdef-envfiles.html)」を参照してください。対応する UI: [設定] タブ/**[環境変数 - オプション]** ## Outputs (*ECSRenderTaskDefinition*/**Outputs**) (必須) ワークフローの実行中にアクションによって出力されるデータを定義します。対応する UI: **[出力]** タブ ## Artifacts (*ECSRenderTaskDefinition*/Outputs/**Artifacts**) (必須) アクションによって生成されたアーティファクトを指定します。このアーティファクトは、他のアクションの入力として参照できます。アーティファクトの詳細 (例を含む) については、「[アクション間でのアーティファクトとファイルの共有](workflows-working-artifacts.md)」を参照してください。対応する UI: [出力] タブ/**[アーティファクト]** ## Name (*ECSRenderTaskDefinition*/Outputs/Artifacts/**Name**) (必須) 更新されたタスク定義ファイルを含むアーティファクトの名前を指定します。デフォルト値は `MyTaskDefinitionArtifact` です。次に、このアーティファクトを **Amazon ECS にデプロイ**アクションへの入力として指定する必要があります。このアーティファクトを **Amazon ECS にデプロイ**アクションへの入力として追加する方法については、「[例: Amazon ECS taskdef を変更する](render-ecs-action-example-workflow.md)」を参照してください。対応する UI: [出力] タブ/[アーティファクト[/**[名前]** ## Files (*ECSRenderTaskDefinition*/Outputs/Artifacts/**Files**) (必須) アーティファクトに含めるファイルを指定します。`task-definition-*` を指定して、更新されたタスク定義ファイル (`task-definition-` で始まる) を含める必要があります。対応する UI: [出力] タブ/[アーティファクト]/**[ファイル]** ## Variables (*ECSRenderTaskDefinition*/Outputs/**Variables**) (必須) レンダリングアクションで設定する変数の名前を指定します。レンダリングアクションは、この変数の値を更新されたタスク定義ファイルの名前 (例: `task-definition-random-string.json`) に設定します。次に、**Amazon ECS へのデプロイ**アクションの**タスク定義** (ビジュアルエディタ) または `task-definition` (YAML エディタ) プロパティに、この変数を指定する必要があります。この変数を **Amazon ECS へのデプロイ**アクションに追加する方法については、「[例: Amazon ECS taskdef を変更する](render-ecs-action-example-workflow.md)」を参照してください。デフォルト: `task-definition` 対応する UI: [出力] タブ/[変数]/**[名前]** フィールド # ワークフローでの変数の使用 *変数*は、Amazon CodeCatalyst ワークフローで参照できる情報を含むキーと値のペアです。変数の値部分は、ワークフロー実行時に実際の値に置き換えられます。ワークフローで使用できる変数には次の 2 種類があります。 + **ユーザー定義変数** - ユーザーが定義するキーと値のペアです。 + **事前定義済み変数** – ワークフローによって自動的に出力されるキーと値のペアです。これらは定義する必要がありません。ワークフローの詳細については、「[ワークフローを使用して構築、テスト、デプロイするワークフローを使用して構築、テスト、デプロイする](workflow.md)」を参照してください。 **注記** CodeCatalyst では [GitHub 出力パラメータ](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter)もサポートしています。これは変数のように動作し、他のアクションで参照できます。詳細については、「[GitHub 出力パラメータをエクスポートする](integrations-github-action-export.md)」および「[GitHub 出力パラメータを参照する](integrations-github-action-referencing.md)」を参照してください。 **Topics** + [ # ユーザー定義変数の使用 ](workflows-using-variables.md) + [ # 事前定義済み変数の使用 ](workflows-using-predefined-variables.md) # ユーザー定義変数の使用 *ユーザー定義変数*は、ユーザーが定義するキーと値のペアです。ユーザー定義変数には次の 2 種類があります。 + **プレーンテキスト変数**、または単に**変数** - これらは、ワークフロー定義ファイル内でプレーンテキストで定義するキーと値のペアです。 + **シークレット** – これらは、Amazon CodeCatalyst コンソールの別の **[シークレット]** ページで定義するキーと値のペアです。*キー* (名前) は公開ラベルで、*値*には非公開にしたい情報が含まれます。ワークフロー定義ファイルではキーのみを指定します。ワークフロー定義ファイル内でパスワードやその他の機密情報の代わりにシークレットを使用します。 **注記** わかりやすくするために、このガイドでは*プレーンテキスト変数*のことを*変数*と呼んでいます。変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 **Topics** + [ # 変数の例 ](workflows-working-with-variables-ex.md) + [ # 変数の定義 ](workflows-working-with-variables-define-input.md) + [ # シークレットの定義 ](workflows-working-with-variables-define-secret.md) + [ # 他のアクションで使用できるように変数をエクスポートする ](workflows-working-with-variables-export-input.md) + [ # 変数を定義するアクションでの変数の参照 ](workflows-working-with-variables-reference-input.md) + [ # 別のアクションによって出力された変数の参照 ](workflows-working-with-variables-reference-action.md) + [ # シークレットの参照 ](workflows-working-with-variables-reference-secret.md) # 変数の例次の例は、ワークフロー定義ファイルで変数を定義して参照する方法を示したものです。変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 **Topics** + [ ## 例: Inputs プロパティを使用した変数の定義 ](#workflows-working-with-variables-ex-define-inputs) + [ ## 例: Steps プロパティを使用した変数の定義 ](#workflows-working-with-variables-ex-define-steps) + [ ## 例: Outputs プロパティを使用した変数のエクスポート ](#workflows-working-with-variables-ex-export-outputs) + [ ## 例: 同じアクション内に定義されている変数の参照 ](#workflows-working-with-variables-ex-refer-current) + [ ## 例: 別のアクションで定義されている変数の参照 ](#workflows-working-with-variables-ex-refer-other) + [ ## 例: シークレットの参照 ](#workflows-working-with-variables-ex-refer-secret) ## 例: Inputs プロパティを使用した変数の定義次の例は、`Inputs` セクションで `VAR1` と `VAR2` の 2 つの変数を定義する方法を示したものです。 ``` Actions: Build: Identifier: aws/build@v1 Inputs: Variables: - Name: VAR1 Value: "My variable 1" - Name: VAR2 Value: "My variable 2" ``` ## 例: Steps プロパティを使用した変数の定義次の例は、`Steps` セクションで `DATE` 変数を明示的に定義する方法を示したものです。 ``` Actions: Build: Identifier: aws/build@v1 Configuration: Steps: - Run: DATE=$(date +%m-%d-%y) ``` ## 例: Outputs プロパティを使用した変数のエクスポート次の例は、`REPOSITORY-URI` と `TIMESTAMP` の 2 つの変数を定義し、`Outputs` セクションを使用してエクスポートする方法を示したものです。 ``` Actions: Build: Identifier: aws/build@v1 Inputs: Variables: - Name: REPOSITORY-URI Value: 111122223333.dkr.ecr.us-east-2.amazonaws.com/codecatalyst-ecs-image-repo Configuration: Steps: - Run: TIMESTAMP=$(date +%m-%d-%y-%H-%m-%s) Outputs: Variables: - REPOSITORY-URI - TIMESTAMP ``` ## 例: 同じアクション内に定義されている変数の参照次の例は、`MyBuildAction` で `VAR1` 変数を指定し、`$VAR1` を使用して同じアクションで参照する方法を示したものです。 ``` Actions: MyBuildAction: Identifier: aws/build@v1 Inputs: Variables: - Name: VAR1 Value: my-value Configuration: Steps: - Run: $VAR1 ``` ## 例: 別のアクションで定義されている変数の参照次の例は、`BuildActionA` で `TIMESTAMP` 変数を指定し、`Outputs` プロパティを使用してそれをエクスポートし、`${BuildActionA.TIMESTAMP}` を使用して `BuildActionB` で参照する方法を示したものです。 ``` Actions: BuildActionA: Identifier: aws/build@v1 Configuration: Steps: - Run: TIMESTAMP=$(date +%m-%d-%y-%H-%m-%s) Outputs: Variables: - TIMESTAMP BuildActionB: Identifier: aws/build@v1 Configuration: Steps: - Run: docker build -t my-ecr-repo/image-repo:latest . - Run: docker tag my-ecr-repo/image-repo:${BuildActionA.TIMESTAMP} # Specifying just '$TIMESTAMP' here will not work # because TIMESTAMP is not a variable # in the BuildActionB action. ``` ## 例: シークレットの参照次の例は、`my-password` シークレットを参照する方法を示したものです。`my-password` はシークレットのキーです。このシークレットのキーと対応するパスワードの値は、ワークフロー定義ファイルで使用する前に CodeCatalyst コンソールの **[シークレット]** ページで指定する必要があります。詳細については、「[シークレットを使用したデータのマスキング](workflows-secrets.md)」を参照してください。 ``` Actions: BuildActionA: Identifier: aws/build@v1 Configuration: Steps: - Run: curl -u LiJuan:${Secrets.my-password} https://example.com ``` # 変数の定義変数は次の 2 つの方法で定義できます。 + ワークフローアクションの `Inputs` セクション – 「[「Inputs」セクションで変数を定義するには](#workflows-to-define-variable-input)」を参照 + ワークフローアクションの `Steps` セクション – 「[「Steps」セクションで変数を定義するには](#workflows-to-define-variable-steps)」を参照 **注記** `Steps` メソッドは CodeCatalyst のビルド、テスト、**GitHub Actions** の各アクションでのみ機能します。これらが `Steps` セクションを含む唯一のアクションであるためです。例については「[変数の例](workflows-working-with-variables-ex.md)」を参照してください。変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 ------ #### [ Visual ] **「Inputs」セクションで変数を定義するには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、変数を設定するアクションを選択します。 1. **[入力]** を選択します。 1. **[変数 - 省略可]** で **[変数を追加]** を選択し、次の操作を行います。アクションで使用できるようにしたい入力変数を定義する名前と値のペアのシーケンスを指定します。変数名に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、変数名で特殊文字とスペースを有効にすることはできません。変数の詳細 (例を含む) については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **「Inputs」セクションで変数を定義するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ワークフローアクションで、次のようなコードを追加します。 ``` action-name: Inputs: Variables: - Name: variable-name Value: variable-value ``` その他の例については、「[変数の例](workflows-working-with-variables-ex.md)」を参照してください。詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ ------ #### [ Visual ] **「Steps」セクションで変数を定義するには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、変数を設定するアクションを選択します。 1. **[設定]** を選択します。 1. **Shell コマンド**と **GitHub Actions YAML** のいずれか利用可能な方で、アクションの `Steps` で変数を明示的または暗黙的に定義します。 + 変数を明示的に定義するには、`Steps` セクションで直接 bash コマンドに変数を含めます。 + 変数を暗黙的に定義するには、アクションの `Steps` セクションで参照されているファイルで変数を指定します。例については「[変数の例](workflows-working-with-variables-ex.md)」を参照してください。詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **「Steps」セクションで変数を定義するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ワークフローアクションで、明示的または暗黙的にアクションの `Steps` セクションで変数を定義します。 + 変数を明示的に定義するには、`Steps` セクションで直接 bash コマンドに変数を含めます。 + 変数を暗黙的に定義するには、アクションの `Steps` セクションで参照されているファイルで変数を指定します。例については「[変数の例](workflows-working-with-variables-ex.md)」を参照してください。詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # シークレットの定義 CodeCatalyst コンソールの **[シークレット]** ページでシークレットを定義します。詳細については、「[シークレットを使用したデータのマスキング](workflows-secrets.md)」を参照してください。例えば、次のようなシークレットを定義できます。 + 名前 (キー): **my-password** + 値: **^\$1H3\$1\$1b9** シークレットを定義したら、ワークフロー定義ファイルでシークレットのキー (**my-password**) を指定できます。これを行う方法の例については、「[例: シークレットの参照](workflows-working-with-variables-ex.md#workflows-working-with-variables-ex-refer-secret)」を参照してください。 # 他のアクションで使用できるように変数をエクスポートする次の手順に従って、アクションから変数をエクスポートし、他のアクションで参照できるようにします。変数をエクスポートする前に、次の点に注意してください。 + 変数が定義されているアクション内でのみ変数を参照する必要がある場合は、エクスポートする必要はありません。 + すべてのアクションが変数のエクスポートをサポートしているわけではありません。アクションがこの機能をサポートしているかどうかを確認するには、以下のビジュアルエディタの手順を実行して、アクションの **[出力]** タブに **[変数]** ボタンが含まれているかどうかを確認します。含まれている場合、変数のエクスポートがサポートされています。 + GitHub アクションから変数をエクスポートするには、「[GitHub 出力パラメータをエクスポートする](integrations-github-action-export.md)」を参照してください。変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 **前提条件** エクスポートする変数が定義済みであることを確認します。詳細については、「[変数の定義](workflows-working-with-variables-define-input.md)」を参照してください。 ------ #### [ Visual ] **変数をエクスポートするには (ビジュアルエディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[ビジュアル]** を選択します。 1. ワークフロー図で、変数のエクスポート元となるアクションを選択します。 1. **[出力]** を選択します。 1. **[変数 - 省略可]** で **[変数を追加]** を選択し、次の操作を行います。アクションをエクスポートする変数の名前を指定します。この変数は、同じアクションの `Inputs` または `Steps` セクションであらかじめ定義されている必要があります。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ #### [ YAML ] **変数をエクスポートするには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 変数のエクスポート元となるアクションで、次のようなコードを追加します。 ``` action-name: Outputs: Variables: - Name: variable-name ``` その他の例については、「[変数の例](workflows-working-with-variables-ex.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 変数を定義するアクションでの変数の参照以下の手順に従って、変数を定義するアクションで変数を参照します。 **注記** GitHub アクションによって生成された変数を参照するには、「[GitHub 出力パラメータを参照する](integrations-github-action-referencing.md)」を参照してください。変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 **前提条件** 参照する変数が定義済みであることを確認します。詳細については、「[変数の定義](workflows-working-with-variables-define-input.md)」を参照してください。 ------ #### [ Visual ] *利用できません。YAML を選択して YAML の手順を表示してください。* ------ #### [ YAML ] **変数を定義するアクションで変数を参照するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. 参照する変数を定義する CodeCatalyst アクションで、次の bash 構文を使用して変数を追加します。 ``` $variable-name ``` 例えば、次のようになります。 ``` MyAction: Configuration: Steps: - Run: $variable-name ``` その他の例については、「[変数の例](workflows-working-with-variables-ex.md)」を参照してください。詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」のアクションのリファレンス情報を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # 別のアクションによって出力された変数の参照他のアクションによって出力された変数を参照するには、次の手順に従います。 **注記** GitHub アクションから出力された変数を参照するには、「[GitHub 出力パラメータを参照する](integrations-github-action-referencing.md)」を参照してください。変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 **前提条件** 参照する変数がエクスポート済みであることを確認します。詳細については、「[他のアクションで使用できるように変数をエクスポートする](workflows-working-with-variables-export-input.md)」を参照してください。 ------ #### [ Visual ] *利用できません。[YAML] を選択して YAML の手順を表示してください。* ------ #### [ YAML ] **別のアクションによって出力された変数を参照するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. CodeCatalyst アクションで、次の構文を使用して変数に参照を追加します。 ``` ${action-group-name.action-name.variable-name} ``` 置き換え前: + *action-group-name* は、変数を出力するアクションを含むアクショングループの名前に置き換えます。 **注記** アクショングループがない場合、または変数が同じアクショングループ内のアクションによって生成される場合は、*action-group-name* を省略しても構いません。 + *action-name* は、変数を出力するアクションの名前に置き換えます。 + *variable-name* は変数の名前に置き換えます。例えば、次のようになります。 ``` MySecondAction: Configuration: Steps: - Run: ${MyFirstAction.TIMESTAMP} ``` その他の例については、「[変数の例](workflows-working-with-variables-ex.md)」を参照してください。詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # シークレットの参照ワークフロー定義ファイルでシークレットを参照する手順については、「[シークレットの使用](workflows-secrets.using.md)」を参照してください。例については、「[例: シークレットの参照](workflows-working-with-variables-ex.md#workflows-working-with-variables-ex-refer-secret)」を参照してください。 # 事前定義済み変数の使用 *事前定義済み変数*は、ワークフローによって自動的に出力され、ワークフローアクションで使用できるキーと値のペアです。変数の詳細については、「[ワークフローでの変数の使用](workflows-working-with-variables.md)」を参照してください。 **Topics** + [ # 事前定義済み変数の参照の例 ](workflows-predefined-examples.md) + [ # 事前定義済み変数の参照 ](workflows-working-with-variables-reference-output-vars.md) + [ # ワークフローが出力する事前定義済み変数の確認 ](workflows-working-with-variables-determine-output-vars.md) + [ # 定義済み変数のリスト ](workflow-ref-action-variables.md) # 事前定義済み変数の参照の例次の例は、ワークフロー定義ファイルで事前定義済み変数を参照する方法を示しています。事前定義済み変数の詳細については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください。 **Topics** + [ ## 例: 「CommitId」事前定義済み変数の参照 ](#workflows-working-with-variables-ex-refer-action) + [ ## 例: 「BranchName」事前定義済み変数の参照 ](#workflows-working-with-variables-ex-branch) ## 例: 「CommitId」事前定義済み変数の参照次の例は、`MyBuildAction` アクションで `CommitId` 事前定義済み変数を参照する方法を示しています。`CommitId` 変数は CodeCatalyst によって自動的に出力されます。詳細については、「[定義済み変数のリスト](workflow-ref-action-variables.md)」を参照してください。この例では、ビルドアクションで使用されている変数を示していますが、どのアクションでも `CommitId` を使用できます。 ``` MyBuildAction: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: #Build Docker image and tag it with a commit ID - Run: docker build -t image-repo/my-docker-image:latest . - Run: docker tag image-repo/my-docker-image:${WorkflowSource.CommitId} ``` ## 例: 「BranchName」事前定義済み変数の参照次の例は、`CDKDeploy` アクションで `BranchName` 事前定義済み変数を参照する方法を示しています。`BranchName` 変数は CodeCatalyst によって自動的に出力されます。詳細については、「[定義済み変数のリスト](workflow-ref-action-variables.md)」を参照してください。この例では、**AWS CDK デプロイ**アクションで使用されている変数を示していますが、どのアクションでも `BranchName` を使用できます。 ``` CDKDeploy: Identifier: aws/cdk-deploy@v2 Inputs: Sources: - WorkflowSource Configuration: StackName: app-stack-${WorkflowSource.BranchName} ``` # 事前定義済み変数の参照 Amazon CodeCatalyst ワークフロー内のどのアクションでも事前定義済み変数を参照できます。ワークフローで事前定義済み変数を参照するには、次の手順に従います。事前定義済み変数の詳細については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください。 **前提条件** `CommitId` など、参照する事前定義済み変数の名前を指定します。詳細については、「[ワークフローが出力する事前定義済み変数の確認](workflows-working-with-variables-determine-output-vars.md)」を参照してください。 ------ #### [ Visual ] *利用できません。YAML を選択して YAML の手順を表示してください。* ------ #### [ YAML ] **事前定義済み変数を参照するには (YAML エディタ)** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. CodeCatalyst アクションで、次の構文を使用して事前定義済み変数参照を追加します。 ``` ${action-group-name.action-name-or-WorkflowSource.variable-name} ``` 置き換え前: + *action-group-name* はアクショングループの名前に置き換えます。 **注記** アクショングループがない場合、または変数が同じアクショングループ内のアクションによって生成される場合は、*action-group-name* を省略しても構いません。 + *action-name-or-WorkflowSource* は以下に置き換えます。変数を出力するアクションの名前。または `WorkflowSource` (変数が `BranchName` または `CommitId` 変数の場合)。 + *variable-name* は変数の名前に置き換えます。例えば、次のようになります。 ``` MySecondAction: Configuration: Steps: - Run: echo ${MyFirstECSAction.cluster} ``` 別の例を紹介します。 ``` MySecondAction: Configuration: Steps: - Run: echo ${WorkflowSource.CommitId} ``` その他の例については、「[事前定義済み変数の参照の例](workflows-predefined-examples.md)」を参照してください。詳細については、アクションの「[ワークフロー YAML 定義](workflow-reference.md)」を参照してください。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 ------ # ワークフローが出力する事前定義済み変数の確認次の手順に従って、ワークフローの実行時に出力される事前定義済み変数を確認します。その後、同じワークフロー内でこれらの変数を参照できます。事前定義済み変数の詳細については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください。 **ワークフローが出力する事前定義済み変数を確認するには** + 次のいずれかを行います。 + **ワークフローを 1 回実行**します。実行が完了すると、ワークフローによって出力された変数が、実行の詳細ページの **[変数]** タブに表示されます。詳細については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。 + **「[定義済み変数のリスト](workflow-ref-action-variables.md)」を参照してください**。このリファレンスには、各事前定義済み変数の変数名 (キー) と値がまとめられています。 **注記** ワークフローの変数の最大合計サイズは「[CodeCatalyst のワークフローのクォータ](workflows-quotas.md)」に記載されています。合計サイズが最大サイズを超えると、最大サイズに達した後に発生するアクションが失敗する可能性があります。 # 定義済み変数のリストワークフロー実行の一部として CodeCatalyst アクションによって自動的に生成される定義済み変数を確認するには、次のセクションを参照してください。事前定義済み変数の詳細については、「[事前定義済み変数の使用](workflows-using-predefined-variables.md)」を参照してください。 **注記** このリストには、CodeCatalyst ソースおよび [CodeCatalyst アクション](workflows-actions.md#workflows-actions-types)によって生成された定義済み変数のみが含まれます。GitHub アクションや CodeCatalyst Labs アクションなど、他のタイプのアクションを使用している場合は、代わりに「[ワークフローが出力する事前定義済み変数の確認](workflows-working-with-variables-determine-output-vars.md)」を参照してください。 **リスト** **注記** すべての CodeCatalyst アクションが定義済み変数を生成するわけではありません。アクションがリストにない場合、変数は生成されません。 + [「BranchName」変数と「CommitId」変数](workflows-sources-variables.md) + [CloudFormation 「スタックをデプロイ」変数](deploy-action-cfn-variables.md) + [「Amazon ECS にデプロイ」する変数](deploy-action-ecs-variables.md) + [「Kubernetes クラスターにデプロイ」変数](deploy-action-eks-variables.md) + [「AWS CDK デプロイ」変数](cdk-dep-action-variables.md) + [「AWS CDK ブートストラップ」変数](cdk-boot-action-variables.md) + [「AWS Lambda 呼び出し」変数](lam-invoke-action-variables.md) + [「Amazon ECS タスク定義のレンダリング」の変数](render-ecs-action-variables.md) # シークレットを使用したデータのマスキングワークフローでは、認証情報などの機密データを使用する必要がある場合があります。シークレットを含むリポジトリへのアクセス権を持つすべてのユーザーがそれらの値を表示できるため、これらの値をリポジトリ内の任意の場所にプレーンテキストで保存することは避ける必要があります。同様に、これらの値はリポジトリ内のファイルとして表示されるため、ワークフロー定義で直接使用すべきではありません。CodeCatalyst では、プロジェクトにシークレットを追加し、ワークフロー定義ファイルでシークレットを参照することで、これらの値を保護できます。アクションごとに最大 5 つのシークレットを設定できます。 **注記** ワークフロー定義ファイル内のパスワードと機密情報を置き換える目的でのみシークレットを使用できます。 **Topics** + [ # シークレットを作成する ](workflows-secrets.creating.md) + [ # シークレットの編集 ](workflows-secrets.editing.md) + [ # シークレットの使用 ](workflows-secrets.using.md) + [ # シークレットの削除 ](workflows-secrets.deleting.md) # シークレットを作成する次の手順に従ってシークレットを作成します。シークレットには、非表示にした方が良い機密情報が含まれています。 **注記** シークレットはアクションに表示され、ファイルに書き込まれる際にマスクされません。 **シークレットを作成する** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[シークレット]** の順に選択します。 1. **[シークレットの作成]** を選択します。 1. 次の情報を入力します。 **名前** シークレットの名前を入力します。 **値** シークレットの値を入力します。これは非表示にした方が良い機密情報です。デフォルトでは値が表示されません。値を表示するには **[値を表示]** を選択します。 **説明** (省略可) シークレットの説明を入力します。 1. **[Create]** (作成) を選択します。 # シークレットの編集以下の手順に従ってシークレットを編集します。 **シークレットを編集するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[シークレット]** の順に選択します。 1. シークレットのリストで、編集するシークレットを選択します。 1. **[編集]** を選択します。 1. 以下のプロパティを編集します。 **値** シークレットの値を入力します。これは非表示にした方が良い値です。デフォルトでは値が表示されません。 **説明** (省略可) シークレットの説明を入力します。 1. **[保存]** を選択します。 # シークレットの使用ワークフローアクションでシークレットを使用するには、シークレットの参照識別子を取得し、ワークフローアクションでその識別子を使用する必要があります。 **Topics** + [ ## シークレットの識別子の取得 ](#workflows-using-secrets.get-identifier) + [ ## ワークフローでのシークレットの参照 ](#workflows-using-secrets.using-identifier) ## シークレットの識別子の取得シークレットの参照識別子を取得するには、次の手順に従います。この識別子はワークフローに追加します。 **シークレットの参照識別子を取得するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[シークレット]** の順に選択します。 1. シークレットのリストで、使用するシークレットを見つけます。 1. **[参照 ID]** 列でシークレットの識別子をコピーします。**[参照 ID]** の構文は次のとおりです。 ``` ${Secrets.} ``` ## ワークフローでのシークレットの参照ワークフローでシークレットを参照するには、次の手順に従います。 **シークレットを参照するには** 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. シークレットの識別子を使用するように YAML を変更します。例えば、`curl` コマンドでシークレットとして保存されているユーザー名とパスワードを使用するには、次のような `Run` コマンドを使用します。 ``` - Run: curl -u : https://example.com ``` 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 # シークレットの削除シークレットとシークレット参照識別子を削除するには、次の手順に従います。 **注記** シークレットを削除する前に、すべてのワークフローアクションからシークレットの参照識別子を削除することをお勧めします。参照識別子を削除せずにシークレットを削除すると、アクションは次回実行時に失敗します。 **ワークフローからシークレットの参照識別子を削除するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。 1. **[編集]** を選択します。 1. **[YAML]** を選択します。 1. ワークフローで次の文字列を検索します。 ``` ${Secrets. ``` すべてのシークレットのすべての参照識別子が検索されます。 1. 選択したシークレットの参照識別子を削除するか、プレーンテキスト値に置き換えます。 1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。 1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。 **シークレットを削除するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. ナビゲーションペインで **[CI/CD]**、**[シークレット]** の順に選択します。 1. シークレットリストで削除するシークレットを選択します。 1. **[削除]** を選択します。 1. **delete** と入力して削除を確定します。 1. **[削除]** を選択します。 # ワークフローのステータスの表示ワークフローのステータスを表示して、対処する必要があるワークフロー構成の問題がないかを確認したり、開始に失敗した実行をトラブルシューティングしたりすることができます。CodeCatalyst では、ワークフローのベースとなる[ワークフロー定義ファイル](workflows-concepts.md#workflows-concepts-workflows-def)を作成または更新するたびにワークフローステータスを評価します。 **注記** ワークフローステータスとは異なる、ワークフローの*実行*ステータスを表示することもできます。詳細については、「[ワークフロー実行のステータスと詳細の表示](workflows-view-run.md)」を参照してください。ワークフロー状態のリストについては、「[CodeCatalyst のワークフロー状態](workflows-workflow-status.md)」を参照してください。 **ワークフローのステータスを表示するには** 1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。 1. プロジェクトを選択します。 1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。 1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。ステータスはリスト内のワークフローとともに表示されます。 1. (省略可) ワークフローの名前を選択し、**[ワークフロー定義]** フィールドを見つけます。ワークフローステータスが表示されます。 # CodeCatalyst のワークフローのクォータ次の表では、Amazon CodeCatalyst のワークフローのクォータと制限について説明しています。 Amazon CodeCatalyst でのクォータの詳細については、「[CodeCatalyst のクォータ](quotas.md)」を参照してください。 | | | | --- |--- | | スペースあたりのワークフローの最大数 | 800 | | ワークフロー定義ファイルの最大サイズ | 256 KB | | 1 つのソースイベントで処理されるワークフローファイルの最大数 | 50 | | 1 つのソースイベントで処理されるファイルの最大数 | 4,000 | | スペースあたりのアクティブフリートの最大数 | 10 | | フリートあたりのアクティブコンピューティングインスタンスの最大数 | 20 | | アクションあたりの入力アーティファクトの最大数 | 10 | | アクションあたりの出力アーティファクトの最大数 | 10 | | 1 つのアクションの出力変数の最大合計サイズ | 120 KB | | 出力変数値の最大長 | 値を生成するアクションに応じて、500 文字以上。アクションの制限を超えた場合、値が切り捨てられる場合があります。 | | ワークフロー実行中に生成されたアーティファクトを保持する最大日数 | 30 | | アクションあたりのレポートの最大数 | 50 | | テストレポートあたりのテストケースの最大数 | 20,000 | | コードカバレッジレポートあたりのファイルの最大数 | 20,000 | | レポートあたりのソフトウェアコンポジション分析結果の最大数 | 20,000 | | 静的分析レポートあたりのファイルの最大数 | 20,000 | | スペースあたりの同時ワークフロー実行の最大数 | 100 | | ワークフローあたりのアクションの最大数 | 50 | | ワークフローあたりの同時実行アクションの最大数 | 50 | | スペースあたりの同時実行アクションの最大数 | 200 | | アクションを実行できる最長時間 | ビルドアクションとテストアクションの場合、タイムアウトは 8 時間です。他のすべてのアクションでは、タイムアウトは 1 時間です。 | | スペースあたりの AWS アカウントに関連付けられる環境の最大数 | 5,000 | | アクションあたりのシークレットの最大数 | 5 | | スペースあたりのシークレットの最大数 | 500,000 | # ワークフロー実行の状態ワークフロー実行は、次に示す状態のいずれかになります。 + **成功** – ワークフローの実行が正常に処理されました。 + **失敗** – ワークフロー実行で 1 つ以上のアクションが失敗しました。 + **進行中** – ワークフロー実行は現在処理中です。 + **停止** – 進行中にワークフロー実行をユーザーが停止しました。 + **停止中** – ワークフロー実行は現在停止中です。 + **キャンセル** – 実行の進行中に関連ワークフローが削除または更新されたため、ワークフロー実行が CodeCatalyst によってキャンセルされました。 + **置換** - [優先実行モード](workflows-configure-runs.md#workflows-configure-runs-superseded)を構成している場合にのみ発生します。あるワークフロー実行よりも後続のワークフロー実行が優先されたため、ワークフロー実行が CodeCatalyst によってキャンセルされました。 # CodeCatalyst のワークフロー状態ワークフローは次のいずれかの状態になります。 + **有効** – ワークフローは実行可能で、[トリガー](workflows-add-trigger.md#workflows-add-trigger.title)によってアクティブ化できます。次の条件の両方を満たしている場合にワークフローが有効としてマークされます。 + ワークフロー定義ファイルが有効である。 + トリガー、プッシュトリガー、または現在のブランチのファイルを使用して実行されるプッシュトリガーがワークフローにない。詳細については、「[トリガーとブランチの使用ガイドライン](workflows-add-trigger-considerations.md)」を参照してください。 + **無効** – ワークフローの定義ファイルが無効です。ワークフローは手動で実行することも、トリガーを介して自動的に実行することもできません。有効でないワークフローには、CodeCatalyst コンソールで **[ワークフロー定義に *n* 件のエラーがあります]** というメッセージ (または類似のメッセージ) が表示されます。次の条件を満たしている場合にワークフローが無効としてマークされます。 + ワークフロー定義ファイルは誤って構成されている。誤って構成されているワークフロー定義ファイルを修正するには、「[「ワークフロー定義に *n* 個のエラーがあります」というエラーを解決修正するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-asterisks)」を参照してください。 + **非アクティブ** – ワークフロー定義は有効ですが、手動で実行することも、トリガーを介して自動的に実行することもできません。次の条件の両方を満たしている場合にワークフローが非アクティブとしてマークされます。 + ワークフロー定義ファイルが有効である。 + ワークフロー定義ファイルが現在存在するブランチとは異なるブランチを指定するプッシュトリガーがワークフロー定義ファイルに含まれている。詳細については、「[トリガーとブランチの使用ガイドライン](workflows-add-trigger-considerations.md)」を参照してください。ワークフローを**非アクティブ**から**アクティブ**に切り替えるには、「[「ワークフローが非アクティブです」というメッセージを解決するにはどうすればよいですか?](troubleshooting-workflows.md#troubleshooting-workflows-inactive)」を参照してください。 **注記** **非アクティブ**状態のワークフローが多数ある場合は、ビューからフィルタリングできます。非アクティブなワークフローを除外するには、**[ワークフロー]** ページの上部にある **[ワークフローをフィルタリング]** フィールドを選択し、**[ステータス]**、**[ステータス \$1= 等しくない**]、**[非アクティブ]** の順に選択します。 **注記** 後で削除するリソース (パッケージリポジトリなど) がワークフローで指定されている場合、CodeCatalyst ではこの変更を検出せず、ワークフローを引き続き有効としてマークします。これらのタイプの問題はワークフロー実行時に検出されます。 # ワークフロー YAML 定義ワークフロー定義ファイルのリファレンスドキュメントを次に示します。 *ワークフロー定義ファイル*は、ワークフローを記述する YAML ファイルです。デフォルトでは、ファイルは[ソースリポジトリ](source-repositories.md)のルートにある `~/.codecatalyst/workflows/` フォルダに保存されます。ファイルには .yml または .yaml 拡張子を使用でき、拡張子は小文字にする必要があります。ワークフロー定義ファイルを作成および編集するには、vim などのエディタを使用するか、CodeCatalyst コンソールのビジュアルエディタまたは YAML エディタを使用できます。詳細については、「[CodeCatalyst コンソールのビジュアルエディタと YAML エディタの使用](workflow.md#workflow.editors)」を参照してください。 **注記** 後続の YAML プロパティのほとんどには、対応する UI 要素がビジュアルエディタにあります。UI 要素を検索するには、**Ctrl\$1F** を使用します。要素は、関連付けられた YAML プロパティと共に一覧表示されます。 **Topics** + [ ## ワークフロー定義ファイルの例 ](#workflow.anatomy) + [ ## 構文ガイドラインと規則 ](#workflow.terms.syntax.conv) + [ ## 最上位プロパティ ](#workflow.top.level) ## ワークフロー定義ファイルの例単純なワークフロー定義ファイルの例を次に示します。これには、いくつかの最上位プロパティ、`Triggers` セクション、および `Build` と `Test` の 2 つのアクションを含む `Actions` セクションが含まれます。詳細については、「[ワークフロー定義ファイルについて](workflow.md#workflow.example)」を参照してください。 ``` Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main Actions: Build: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: docker build -t MyApp:latest . Test: Identifier: aws/managed-test@v1 DependsOn: - Build Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: npm install - Run: npm run test ``` ## 構文ガイドラインと規則このセクションでは、ワークフロー定義ファイルの構文ルールと、このリファレンスドキュメントで使用される命名規則について説明します。 ### YAML 構文ガイドラインワークフロー定義ファイルは YAML で記述され、[YAML 1.1 仕様](https://yaml.org/spec/)に準拠しているため、その仕様で許可されているものはすべてワークフロー YAML でも許可されます。YAML を初めて使うユーザーのために、有効な YAML コードを提供するための簡単なガイドラインをいくつか紹介します。 + **大文字と小文字の区別**: ワークフロー定義ファイルでは大文字と小文字が区別されるため、このドキュメントに示す大文字と小文字の区別を使用してください。 + **特殊文字**: 次のいずれかの特殊文字を含むプロパティ値を引用符または二重引用符で囲むことをお勧めします。`{`、`}`、`[`、`]`、&、`*`、`#`、`?`、`|`、`-`、<、>、`=`、`!`、`%`、`@`、`:`、```、および `,` 引用符を含めない場合、前述の特殊文字が予期しない方法で解釈されることがあります。 + **プロパティ名**: プロパティ*名* (プロパティ*値*ではない) に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符または二重引用符を使用して、プロパティ名の特殊文字とスペースを有効にすることはできません。許可されないもの: `'My#Build@action'` `My#Build@action` `My Build Action` 許可されるもの: `My-Build-Action_1` + **エスケープコード**: プロパティ値にエスケープコード (`\n` や `\t` など) が含まれている場合は、次のガイドラインに従ってください。 + 一重引用符を使用してエスケープコードを文字列として返します。例えば、`'my string \n my string'` は文字列 `my string \n my string` を返します。 + 二重引用符を使用してエスケープコードを解析します。例えば、`"my string \n my new line"` は次を返します。 ``` my string my new line ``` + **コメント**: コメントには `#` を付けます。例: ``` Name: MyWorkflow # This is a comment. SchemaVersion: 1.0 ``` + **トリプルダッシュ (`---`)**: YAML コードでは `---` を使用しないでください。CodeCatalyst は、`---` の後にくるものすべてを無視します。 ### 命名規則このガイドでは、ワークフロー定義ファイルの主な項目を指すために*プロパティ*と*セクション*という用語を使用します。 + *プロパティ*は、コロン (`:`) を含む任意の項目です。例えば、次のコードスニペットでは、`Name`、`SchemaVersion`、`RunMode`、`Triggers`、`Type`、および `Branches` はすべてプロパティです。 + *セクション*は、サブプロパティを持つ任意のプロパティです。次のコードスニペットには、1 つの `Triggers` セクションがあります。 **注記** このガイドでは、コンテキストに応じて、「セクション」が「プロパティ」と呼ばれたり、「プロパティ」が「セクション」と呼ばれたりする場合があります。 ``` Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main ``` ## 最上位プロパティワークフロー定義ファイルの最上位プロパティに関するリファレンスドキュメントを次に示します。 ``` # Name Name: workflow-name # Schema version SchemaVersion: 1.0 # Run mode RunMode: QUEUED|SUPERSEDED|PARALLEL # Compute Compute: ... # Triggers Triggers: ... # Actions Actions: ... ``` ### Name (必須) ワークフローの名前。ワークフロー名はワークフローリストに表示され、通知とログに記載されます。ワークフロー名とワークフロー定義ファイル名は一致させることも、別の名前を付けることもできます。ワークフロー名は一意である必要はありません。ワークフロー名に使用できるのは、英数字 (a～z、A～Z、0～9)、ハイフン (-)、アンダースコア (\$1) のみです。スペースは使用できません。引用符を使用して、ワークフロー名の特殊文字とスペースを有効にすることはできません。対応する UI: ビジュアルエディタ/ワークフロープロパティ/**ワークフロー名** ### SchemaVersion (必須) ワークフロー定義のスキーマバージョン。現在、有効な値は `1.0` のみです。対応する UI: *なし* ### RunMode (オプション) CodeCatalyst が複数の実行を処理する方法。次のいずれかの値を使用できます。 + `QUEUED` – 複数の実行がキューに入れられ、順番に実行されます。キューには最大 50 個の実行を入れることができます。 + `SUPERSEDED` – 複数の実行がキューに入れられ、順番に実行されます。キューには 1 つの実行しか入れられないため、2 つの実行が同じキューに一緒に存在する場合、後の実行が前の実行に取って代わり (引き継ぎ)、前の実行はキャンセルされます。 + `PARALLEL` – 複数の実行が同時に行われます。このプロパティが省略されている場合、デフォルトは `QUEUED` です。詳細については、「[実行のキュー動作の構成](workflows-configure-runs.md)」を参照してください。対応する UI: ビジュアルエディタ/ワークフロープロパティ/アドバンスト/**実行モード** ### Compute (オプション) ワークフローアクションの実行に使用されるコンピューティングエンジンです。コンピューティングはワークフローレベルまたはアクションレベルで指定できますが、両方を指定することはできません。ワークフローレベルで指定すると、コンピューティング設定はワークフローで定義されたすべてのアクションに適用されます。ワークフローレベルでは、同じインスタンスで複数のアクションを実行することもできます。詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。コンピューティングの詳細については、「[コンピューティングイメージとランタイムイメージの構成](workflows-working-compute.md)」を参照してください。対応する UI: *なし* ``` Name: MyWorkflow SchemaVersion: 1.0 ... Compute: Type: EC2 | Lambda Fleet: fleet-name SharedInstance: true | false ``` #### Type (Compute/**Type**) (`Compute` が設定されている場合は必須) コンピューティングエンジンのタイプ。次のいずれかの値を使用できます。 + **EC2** (ビジュアルエディタ) または `EC2` (YAML エディタ) アクション実行時の柔軟性を目的として最適化されています。 + **Lambda** (ビジュアルエディタ) または `Lambda` (YAML エディタ) アクションの起動速度を最適化しました。コンピューティングタイプの詳細については、「[コンピューティングタイプ](workflows-working-compute.md#compute.types)」を参照してください。対応する UI: ビジュアルエディタ/ワークフロープロパティ/アドバンスト/**コンピューティングタイプ** #### Fleet (Compute/**Fleet**) (オプション) ワークフローまたはワークフローアクションを実行するマシンまたはフリートを指定します。オンデマンドフリートでは、アクションが開始すると、ワークフローは必要なリソースをプロビジョニングし、アクションが完了するとマシンは破棄されます。オンデマンドフリートの例: `Linux.x86-64.Large`、`Linux.x86-64.XLarge`。オンデマンドフリートの詳細については、「[オンデマンドフリートのプロパティ](workflows-working-compute.md#compute.on-demand)」を参照してください。プロビジョニングされたフリートでは、ワークフローアクションを実行するように専用マシンのセットを設定します。これらのマシンはアイドル状態のままで、アクションをすぐに処理できます。プロビジョニングされたフリートの詳細については、「[プロビジョニングされたフリートのプロパティ](workflows-working-compute.md#compute.provisioned-fleets)」を参照してください。 `Fleet` を省略した場合、デフォルトは `Linux.x86-64.Large` です。コンピューティングフリートの詳細については、「[コンピューティングフリート](workflows-working-compute.md#compute.fleets)」を参照してください。対応する UI: ビジュアルエディタ/ワークフロープロパティ/アドバンスト/**コンピューティングフリート** #### SharedInstance (Compute/**SharedInstance**) (オプション) アクションのコンピューティング共有機能を指定します。コンピューティング共有では、ワークフロー内のアクションは同じインスタンス (ランタイム環境イメージ) で実行されます。次のいずれかの値を使用できます。 + `TRUE` は、ランタイム環境イメージがワークフローアクション間で共有されることを意味します。 + `FALSE` は、ワークフロー内のアクションごとに個別のランタイム環境イメージが開始および使用されるため、追加の設定なしではアーティファクトや変数などのリソースを共有できないことを意味します。コンピューティング共有の詳細については、「[アクション間でのコンピューティングの共有する](compute-sharing.md)」を参照してください。対応する UI: *なし* ### Triggers (オプション) このワークフローの 1 つ以上のトリガーのシーケンス。トリガーが指定されていない場合は、ワークフローを手動で開始する必要があります。トリガーについての詳細は、「[トリガーを使用したワークフロー実行の自動的な開始](workflows-add-trigger.md)」を参照してください。対応する UI: ビジュアルエディタ/ワークフロー図/**トリガー** ``` Name: MyWorkflow SchemaVersion: 1.0 ... Triggers: - Type: PUSH Branches: - branch-name FilesChanged: - folder1/file - folder2/ - Type: PULLREQUEST Events: - OPEN - CLOSED - REVISION Branches: - branch-name FilesChanged: - file1.txt - Type: SCHEDULE # Run the workflow at 10:15 am (UTC+0) every Saturday Expression: "15 10 ? * 7 *" Branches: - branch-name ``` #### Type (Triggers/**Type**) (`Triggers` が設定されている場合は必須) トリガーのタイプを指定します。次のいずれかの値を使用できます。 + **プッシュ** (ビジュアルエディタ) または `PUSH` (YAML エディタ）プッシュトリガーでは、変更がソースリポジトリにプッシュされたときにワークフロー実行を開始します。ワークフロー実行では、プッシュ*先*のブランチ (つまり、送信先ブランチ) 内のファイルが使用されます。 + **プルリクエスト** (ビジュアルエディタ) または `PULLREQUEST` (YAML エディタ）プルリクエストトリガーでは、プルリクエストがソースリポジトリでオープン、更新、またはクローズされたときにワークフロー実行を開始します。ワークフロー実行では、プル*元*のブランチ (つまり、送信元ブランチ) 内のファイルが使用されます。 + **スケジュール** (ビジュアルエディタ) または `SCHEDULE` (YAML エディタ）スケジュールトリガーでは、指定した cron 式で定義されているスケジュールに従ってワークフロー実行を開始します。ブランチのファイルを使用して、ソースリポジトリ内のブランチごとに個別のワークフロー実行が開始されます (トリガーがアクティブ化するブランチを制限するには、**[ブランチ]** フィールド (ビジュアルエディタ) または `Branches` プロパティ (YAML エディタ) を使用します)。スケジュールトリガーを構成するときは、次のガイドラインに従ってください。 + ワークフロー 1 つにつきスケジュールトリガーを 1 つだけ使用してください。 + CodeCatalyst スペース内で複数のワークフローを定義している場合は、同時に開始するようスケジュールするワークフローは 10 個までにすることをお勧めします。 + トリガーの cron 式を設定する際は、実行間隔に十分な時間を確保してください。詳細については、「[Expression](#workflow.triggers.expression)」を参照してください。例については「[例: ワークフローのトリガー](workflows-add-trigger-examples.md)」を参照してください。対応する UI: ビジュアルエディタ/ワークフロー図/トリガー/**トリガータイプ** #### Events (Triggers/**Events**) (トリガー `Type` が `PULLREQUEST` に設定されている場合は必須) ワークフロー実行を開始するプルリクエストイベントのタイプを指定します。有効な値を次に示します。 + **プルリクエストが作成されました** (ビジュアルエディタ) または `OPEN` (YAML エディタ）プルリクエストが作成されるとワークフロー実行が開始されます。 + **プルリクエストはクローズされました** (ビジュアルエディタ) または `CLOSED` (YAML エディタ）プルリクエストがクローズされるとワークフロー実行が開始されます。`CLOSED` イベントの動作は理解が難しいため、例を見ることで最もよく理解できます。詳細については「[例: プル、ブランチ、および「CLOSED」イベントを含むトリガー](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close)」を参照してください。 + **プルリクエストに対して新しいリビジョンが作成されます** (ビジュアルエディタ) または `REVISION` (YAML エディタ) プルリクエストに対してリビジョンが作成されるとワークフロー実行が開始されます。プルリクエストが作成されると最初のリビジョンが作成されます。その後、プルリクエストで指定されたソースブランチに新しいコミットがプッシュされるたびに、新しいリビジョンが作成されます。プルリクエストトリガーに `REVISION` イベントを含める場合、`REVISION` は `OPEN` のスーパーセットであるため、`OPEN` イベントは省略しても構いません。同じプルリクエストトリガー内で複数のイベントを指定できます。例については「[例: ワークフローのトリガー](workflows-add-trigger-examples.md)」を参照してください。対応する UI: ビジュアルエディタ/ワークフロー図/トリガー/**プルリクエストのイベント** #### Branches (Triggers/**Branches**) (オプション) ワークフロー実行を開始するタイミングを把握するために、トリガーがモニタリングするソースリポジトリ内のブランチを指定します。正規表現パターンを使用してブランチ名を定義できます。例えば、`main` で始まるすべてのブランチを照合するには `main.*` を使用します。指定するブランチはトリガータイプによって異なります。 + プッシュトリガーでは、プッシュ*先*するブランチ、つまり*送信先*ブランチを指定します。一致するブランチ内のファイルを使用して、一致するブランチごとに 1 つのワークフロー実行が開始されます。例: `main.*`、`mainline` + プルリクエストトリガーでは、プッシュ*先*のブランチ、つまり*送信先*ブランチを指定します。ワークフロー定義ファイルと**ソース**ブランチ内のソースファイル (一致するブランチ*ではない*) を使用して、一致するブランチごとに 1 つのワークフロー実行が開始されます。例: `main.*`、`mainline`、`v1\-.*` (`v1-` で始まるブランチと一致) + スケジュールトリガーでは、スケジュールされた実行で使用するファイルを含むブランチを指定します。ワークフロー定義ファイルと一致するブランチ内のソースファイルを使用して、一致するブランチごとに 1 つのワークフロー実行が開始されます。例: `main.*`、`version\-1\.0` **注記** ブランチを指定*しない*場合、トリガーはソースリポジトリ内のすべてのブランチをモニタリングし、次の場所にあるワークフロー定義ファイルとソースファイルを使用してワークフロー実行を開始します。プッシュ*先*のブランチ (プッシュトリガーの場合)。詳細については、「[例: シンプルなコードプッシュトリガー](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple)」を参照してください。プル*元*のブランチ (プルリクエストトリガーの場合)。詳細については、「[例: シンプルなプルリクエストトリガー](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple)」を参照してください。すべてのブランチ (スケジュールトリガーの場合)。ソースリポジトリ内のブランチごとに 1 つのワークフロー実行が開始されます。詳細については、「[例: シンプルなスケジュールトリガー](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple)」を参照してください。ブランチとトリガーの詳細については、「[トリガーとブランチの使用ガイドライン](workflows-add-trigger-considerations.md)」を参照してください。その他の例については、「[例: ワークフローのトリガー](workflows-add-trigger-examples.md)」を参照してください。対応する UI: ビジュアルエディタ/ワークフロー図/トリガー/**ブランチ** #### FilesChanged (Triggers/**FilesChanged**) (トリガー `Type` が `PUSH` または `PULLREQUEST` に設定されている場合はオプションです。トリガー `Type` が `SCHEDULE` に設定されている場合はサポートされません) ワークフロー実行を開始するタイミングを把握するために、トリガーがモニタリングするソースリポジトリ内のファイルかフォルダを指定します。正規表現を使用して、ファイルの名前またはパスを照合できます。例については「[例: ワークフローのトリガー](workflows-add-trigger-examples.md)」を参照してください。対応する UI: ビジュアルエディタ/ワークフロー図/トリガー/**ファイルの変更** #### Expression (Triggers/**Expression**) (トリガー `Type` が `SCHEDULE` に設定されている場合は必須) スケジュールされたワークフローの実行を行うタイミングを記述する cron 式を指定します。 CodeCatalyst の cron 式では次の 6 フィールド構文を使用します。各フィールドはスペースで区切られます。 *分* *時間* *日* *月* *曜日* *年* **cron 式の例** | 分 | 時間 | 日 | 月 | 曜日 | 年 | 意味 | | --- | --- | --- | --- | --- | --- | --- | | 0 | 0 | ? | \$1 | MON-FRI | \$1 | 毎週月曜日から金曜日の午前 0 時 (UTC\$10) にワークフローを実行します。 | | 0 | 2 | \$1 | \$1 | ? | \$1 | 毎日午前 2 時 (UTC\$10) にワークフローを実行します。 | | 15 | 22 | \$1 | \$1 | ? | \$1 | 毎日午後 10:15 (UTC\$10) にワークフローを実行します。 | | 0/30 | 22-2 | ? | \$1 | 土 - 日 | \$1 | 土曜日から日曜日まで開始日の午後 10 時から翌日の午前 2 時 (UTC\$10) の間、30 分間隔でワークフローを実行します。 | | 45 | 13 | L | \$1 | ? | 2023-2027 | 2023 年から 2027 年まで、月末日の午後 1:45 (UTC\$10) にワークフローを実行します。 | CodeCatalyst で cron 式を指定する場合は、次のガイドラインに従ってください。 + `SCHEDULE` トリガー 1 つにつき cron 式を 1 つ指定してください。 + YAML エディタでは cron 式を二重引用符 (`"`) で囲んでください。 + 協定世界時 (UTC) で時間を指定します。他のタイムゾーンはサポートされていません。 + 実行間隔を 30 分以上に設定します。これより短い間隔はサポートされていません。 + *[日]* フィールドと *[曜日]* フィールドのいずれかを指定します。両方を指定することはできません。一方のフィールドに値またはアスタリスク (`*`) を指定する場合、もう一方のフィールドでは疑問符 (`?`) を使用する必要があります。アスタリスクは「すべて」を意味し、疑問符は「いずれか」を意味します。 cron 式のその他の例、および `?`、`*`、`L` などのワイルドカードの情報については、「*Amazon EventBridge ユーザーガイド*」の「[Cron expressions reference](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html)」を参照してください。EventBridge と CodeCatalyst で cron 式はまったく同じように動作します。スケジュールトリガーの例については、「[例: ワークフローのトリガー](workflows-add-trigger-examples.md)」を参照してください。対応する UI: ビジュアルエディタ/ワークフロー図/トリガー/**スケジュール** ### アクションこのワークフローの 1 つ以上のアクションのシーケンス。CodeCatalyst は、ビルドアクションやテストアクションなど、さまざまなタイプの機能を提供する複数のアクションタイプをサポートしています。各アクションタイプには、次が含まれています。 + アクションの一意のハードコードされた ID を示す `Identifier` プロパティ。例えば、`aws/build@v1` はビルドアクションを識別します。 + アクションに固有のプロパティを含む `Configuration` セクション。各アクションタイプの詳細については、「[アクションタイプ](workflows-actions.md#workflows-actions-types)」を参照してください。[アクションタイプ](workflows-actions.md#workflows-actions-types) トピックには、各アクションのドキュメントへのリンクがあります。ワークフロー定義ファイル内のアクションとアクショングループの YAML リファレンスを次に示します。 ``` Name: MyWorkflow SchemaVersion: 1.0 ... Actions: action-or-gate-name: Identifier: identifier Configuration: ... #Action groups action-group-name: Actions: ... ``` #### action-or-gate-name (Actions/*action-or-gate-name*) (必須) *action-name* を、アクションに付ける名前に置き換えます。アクション名はワークフロー内で一意のものであり、英数字、ハイフン、アンダースコアのみを使用する必要があります。構文ルールの詳細については、「[YAML 構文ガイドライン](#workflow.syntax.conv)」を参照してください。制限など、アクションの命名方法の詳細については、「[action-or-gate-name](#workflow.actions.name)」を参照してください。対応する UI: ビジュアルエディタ/*action-name*/[設定] タブ/**[アクション名]** または **[アクション表示名]** #### action-group-name (Actions/*action-group-name*) (オプション) *アクショングループ*には 1 つ以上のアクションが含まれています。アクションをアクショングループにグループ化すると、ワークフローを整理するのに役立ち、異なるグループ間の依存関係を設定できるようになります。 *action-group-name* を、アクショングループに付ける名前に置き換えます。アクショングループ名はワークフロー内で一意のものであり、英数字、ハイフン、アンダースコアのみを使用する必要があります。構文ルールの詳細については、「[YAML 構文ガイドライン](#workflow.syntax.conv)」を参照してください。アクショングループの詳細については、「[アクショングループへのアクションのグループ化](workflows-group-actions.md)」を参照してください。対応する UI: *なし*