Amazon CodeCatalyst は新規のお客様には提供されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「[CodeCatalyst から移行する方法](migration.md)」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ワークフローの実行
*実行*はワークフローの 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. アクションによって処理されなかった (通常は前のアクションが失敗したことが原因) のいずれかです。