Amazon CodeCatalyst 不再向新客戶開放。現有客戶可以繼續正常使用該服務。如需詳細資訊，請參閱[如何從 CodeCatalyst 遷移](migration.md)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 執行工作流程
*執行*是工作流程的單一迭代。在執行期間，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. 開啟 CodeCatalyst 主控台，網址為 https：//[https://codecatalyst.aws/](https://codecatalyst.aws/)。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 選擇工作流程的名稱。您可以依定義工作流程的來源儲存庫或分支名稱進行篩選，或依工作流程名稱或狀態進行篩選。
1. 選擇**執行**。
# 使用觸發程序自動啟動工作流程執行
您可以使用工作流程觸發來自動啟動 Amazon CodeCatalyst 工作流程執行。
*工作流程觸發*或只是*觸發*，可讓您在特定事件發生時自動啟動工作流程執行，例如程式碼推送。您可能想要設定觸發條件，讓您的軟體開發人員無需透過 CodeCatalyst 主控台手動啟動工作流程執行。
您可以使用三種類型的觸發：
+ **推送** – 程式碼推送觸發會在推送遞交時啟動工作流程執行。
+ **提取請求** – 提取請求觸發會在建立、修訂或關閉提取請求時啟動工作流程執行。
+ **排程** – 排程觸發程序會導致工作流程執行從您定義的排程開始。考慮使用排程觸發條件來執行軟體的夜間組建，以便軟體開發人員可以在隔天早上使用最新的組建。
您可以單獨使用推送、提取請求和排程觸發，或在相同的工作流程中結合使用。
觸發是選用的，如果您未設定任何 ，您只能手動啟動工作流程。
**提示**
若要查看執行中的觸發條件，請使用藍圖啟動專案。大多數藍圖都包含具有觸發條件的工作流程。在藍圖的工作流程定義檔案中尋找 `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)
+ [範例：具有提取、分支和「關閉」事件的觸發](#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 會使用 Workfow 定義檔案和 上的其他來源檔案啟動工作流程執行`main`。
另一個範例是，如果您將遞交推送至 `feature-branch-123`，CodeCatalyst 會使用 Workfow 定義檔案和 上的其他來源檔案啟動工作流程執行`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 會使用 Workfow 定義檔案和 上的其他來源檔案啟動工作流程執行`feature-123`。
```
Triggers:
- Type: PULLREQUEST
Events:
- OPEN
- REVISION
```
## 範例：簡單的排程觸發
下列範例顯示的觸發會在每個週一至週五的午夜 (UTC\$10) 啟動工作流程執行。
啟用此觸發條件時，CodeCatalyst 會針對來源儲存庫中的每個分支啟動單一工作流程執行，其中包含具有此觸發條件的工作流程定義檔案。
例如，如果您的來源儲存庫中有三個分支，`main`、`release-v1``feature-123`、，且每個分支都包含一個工作流程定義檔案，其觸發條件如下，則 CodeCatalyst 會啟動三個工作流程執行：一個使用 中的檔案`main`，另一個使用 中的檔案`release-v1`，另一個使用 中的檔案`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-`。
例如，如果您的來源儲存庫`bugfix-2`中有名為 `main`、`bugfix-1`、 `release-v1`和 的分支，CodeCatalyst 會啟動兩個工作流程執行：一個使用 中的檔案`main`，另一個使用 中的檔案`release-v1`。它*不會*啟動 `bugfix-1`和 `bugfix-1`分支的工作流程執行。
```
Triggers:
- Type: SCHEDULE
Expression: "15 18 * * ? *"
Branches:
- main
- release\-.*
```
如需您可以在 `Expression` 屬性中使用的 cron 表達式的更多範例，請參閱 [Expression](workflow-reference.md#workflow.triggers.expression)。
## 範例：具有排程、推送和分支的觸發
下列範例顯示每天午夜 (UTC\$10) 開始工作流程執行的觸發，以及每當程式碼推送到`main`分支時。
在此範例中：
+ 工作流程執行會在每天午夜開始。工作流程執行會使用工作流程定義檔案和`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
```
## 範例：具有提取、分支和「關閉」事件的觸發
下列範例顯示每當提取請求在開頭為 的分支上關閉時，啟動工作流程執行的觸發`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 多工作流程設定中的觸發
此範例說明如何在想要使用單獨的 Amazon CodeCatalyst 工作流程進行持續整合 (CI) 和持續部署 (CD) 時設定觸發。
在此案例中，您會設定兩個工作流程：
+ **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` 程式碼指出每當軟體開發人員建立提取請求 （或修改[請求](pull-requests-update.md))，要求將其功能分支合併到`main`分支時， 會自動啟動工作流程執行。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：**對於推送和提取請求觸發，如果您要指定分支，您必須在觸發組態中指定目的地 （或 'to') 分支。切勿指定來源 （或 'from') 分支。
在下列範例中，從任何分支推送以`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`)。檢閱**指導方針 2**，了解為什麼工作流程永遠不會使用 中的檔案自動執行`test`。
另請考慮下列提取請求觸發條件：
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
如果包含此觸發條件的工作流程定義檔案存在於 中`main`，則工作流程永遠不會使用 中的檔案執行`main`。（不過，如果您從 建立`test`分支`main`，工作流程將使用 中的檔案執行`test`。) 檢閱**指南 3** 以了解原因。
# 將觸發條件新增至工作流程
使用下列指示，將推送、提取或排程觸發新增至 Amazon CodeCatalyst 工作流程。
關於觸發條件的詳細資訊，請參閱 [使用觸發程序自動啟動工作流程執行](workflows-add-trigger.md)。
------
#### [ Visual ]
**新增觸發條件 （視覺化編輯器）**
1. 在 https：//[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 編輯器）。)
設定排程觸發時，請遵循下列準則：
+ 每個工作流程僅使用一個排程觸發。
+ 如果您已在 CodeCatalyst 空間中定義多個工作流程，建議您排定最多 10 個工作流程同時啟動。
+ 請務必在執行之間設定具有足夠時間的觸發條件 cron 表達式。如需詳細資訊，請參閱[Expression](workflow-reference.md#workflow.triggers.expression)。
如需範例，請參閱 [範例：工作流程中的觸發條件](workflows-add-trigger-examples.md)。
**提取請求的事件**
只有在您選取**提取請求**觸發類型時，才會顯示此欄位。
指定將啟動工作流程執行的提取請求事件類型。以下是有效值：
+ **提取請求已建立** （視覺化編輯器） 或 `OPEN`(YAML 編輯器）
建立提取請求時，會啟動工作流程執行。
+ **提取請求已關閉** （視覺化編輯器） 或 `CLOSED`(YAML 編輯器）
關閉提取請求時，會啟動工作流程執行。`CLOSED` 事件的行為很棘手，最好透過範例了解。如需詳細資訊，請參閱[範例：具有提取、分支和「關閉」事件的觸發](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close)。
+ **進行新的修訂以提取請求 **（視覺化編輯器） 或 `REVISION`(YAML 編輯器）
建立提取請求的修訂時，會啟動工作流程執行。第一個修訂會在建立提取請求時建立。之後，每次有人將新的遞交推送到提取請求中指定的來源分支時，都會建立新的修訂。如果您在提取請求觸發中包含`REVISION`事件，您可以省略該`OPEN`事件，因為 `REVISION` 是 的超集`OPEN`。
您可以在相同的提取請求觸發中指定多個事件。
如需範例，請參閱 [範例：工作流程中的觸發條件](workflows-add-trigger-examples.md)。
**排程**
只有在您選取**排程**觸發類型時，才會顯示此欄位。
指定 cron 表達式，描述您希望排程工作流程執行的時間。
CodeCatalyst 中的 Cron 表達式使用以下六欄位語法，其中每個欄位以空格分隔：
*分鐘* *小時* *days-of-month* *日 年* ** *days-of-week*
**Cron 表達式的範例**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/codecatalyst/latest/userguide/workflows-add-trigger-add.html)
在 CodeCatalyst 中指定 Cron 表達式時，請務必遵循下列準則：
+ 指定每個`SCHEDULE`觸發的單一 Cron 表達式。
+ 在 YAML 編輯器中以雙引號 (`"`) 括住 Cron 表達式。
+ 以國際標準時間 (UTC) 指定時間。不支援其他時區。
+ 在執行之間設定至少 30 分鐘。不支援更快速的節奏。
+ 指定*days-of-month*或*days-of-week*欄位，但不能同時指定兩者。如果您在其中一個欄位中指定值或星號 (`*`)，則必須在另一個欄位中使用問號 (`?`)。星號表示「全部」，問號表示「任何」。
如需 Cron 表達式的更多範例，以及 `?`、 `*`和 等萬用字元的相關資訊`L`，請參閱《*Amazon EventBridge 使用者指南*》中的 [Cron 表達式參考](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html)。EventBridge 和 CodeCatalyst 中的 Cron 表達式的運作方式完全相同。
如需排程觸發的範例，請參閱 [範例：工作流程中的觸發條件](workflows-add-trigger-examples.md)。
**分支**和**分支模式**
(選用)
在您的來源儲存庫中指定觸發器監控的分支，以便知道何時啟動工作流程執行。您可以使用 regex 模式來定義分支名稱。例如，使用 `main.*` 來比對以 開頭的所有分支`main`。
要指定的分支會根據觸發類型而有所不同：
+ 對於推送觸發，指定您要推送*的*分支，也就是*目的地*分支。每個相符分支將使用相符分支中的檔案啟動一個工作流程執行。
範例: `main.*`, `mainline`
+ 對於提取請求觸發，指定您要推送*的*分支，也就是*目的地*分支。每個相符分支都會啟動一個工作流程執行，並使用來源分支 (*而非*相符分支） 中的工作流程定義檔案和**來源**檔案。
範例：`main.*`、`mainline`、 `v1\-.*`（符合開頭為 的分支`v1-`)
+ 針對排程觸發，指定包含您希望排程執行使用之檔案的分支。每個相符分支都會啟動一個工作流程執行，並使用相符分支中的工作流程定義檔案和來源檔案。
範例: `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)。
所有分支 （用於排程觸發）。您的來源儲存庫中的每個分支都會啟動一個工作流程執行。如需詳細資訊，請參閱[範例：簡單的排程觸發](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：//[https://codecatalyst.aws/](https://codecatalyst.aws/) 開啟 CodeCatalyst 主控台。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 選擇工作流程的名稱。您可以依定義工作流程的來源儲存庫或分支名稱進行篩選，或依工作流程名稱或狀態進行篩選。
1. 選擇**編輯**。
1. 選擇 **YAML**。
1. 使用下列範例做為指南，新增`Triggers`區段和基礎屬性。如需詳細資訊，請參閱《[Triggers](workflow-reference.md#triggers-reference)》中的 [工作流程 YAML 定義](workflow-reference.md)。
程式碼推送觸發程序可能如下所示：
```
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. 開啟 CodeCatalyst 主控台，網址為 https：//[https://codecatalyst.aws/](https://codecatalyst.aws/)。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 選擇工作流程的名稱。您可以依定義工作流程的來源儲存庫或分支名稱進行篩選，或依工作流程名稱或狀態進行篩選。
1. 選擇**編輯**。
1. 選擇**視覺化**。
1. 選擇工作流程圖表中的**來源**方塊。
1. 在**觸發**下，選擇垃圾桶圖示，從工作流程中移除 `Triggers`區段。
1. （選用） 選擇**驗證**以在遞交之前驗證工作流程的 YAML 程式碼。
1. 選擇**遞交**，輸入遞交訊息，然後再次選擇**遞交**。
------
#### [ YAML ]
**移除「觸發器」區段 (YAML 編輯器）**
1. 在 https：//[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：//[https://codecatalyst.aws/](https://codecatalyst.aws/) 開啟 CodeCatalyst 主控台。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 在**工作流程**下，選擇**執行**，然後從清單中選擇進行中執行。
1. 選擇**停止**。
# 閘道工作流程執行
除非符合特定條件，否則*閘道*是一種工作流程元件，可用來防止工作流程執行繼續進行。閘道的範例是**核准**閘道，使用者必須在 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)。
## 我可以設定閘道以平行於另一個動作執行嗎？
否。Gates 只能在動作之前或之後執行。如需詳細資訊，請參閱[定序閘道和動作](workflows-gates-depends-on.md)。
## 我可以使用閘道來防止工作流程執行啟動嗎？
是，具有資格。
您可以防止工作流程執行*執行任務*，這與防止工作流程*啟動*略有不同。
若要防止工作流程執行任務，請在工作流程中第一個動作之前新增閘道。在此案例中，工作流程執行*將開始*，這表示它將下載您的來源儲存庫檔案，但在閘道解除鎖定之前，將無法執行任務。
**注意**
開始然後被閘道封鎖的工作流程仍會計入*每個空間配額和其他配額的並行工作流程執行數目上限*。為了確保您不超過工作流程配額，請考慮使用工作流程觸發條件來有條件地啟動工作流程，而不是使用閘道。也請考慮使用提取請求核准規則，而非閘道。如需配額、觸發條件和提取請求核准規則的詳細資訊，請參閱 [CodeCatalyst 中工作流程的配額](workflows-quotas.md)、 [使用觸發程序自動啟動工作流程執行](workflows-add-trigger.md)和 [管理將提取請求與核准規則合併的要求](source-pull-requests-approval-rules.md)。
## 閘道的限制
Gates 有下列限制：
+ Gates 無法與運算共用功能搭配使用。如需使用此功能的詳細資訊，請參閱「[跨動作共用運算](compute-sharing.md)」。
+ 動作群組內無法使用閘道。如需動作群組的詳細資訊，請參閱 [將動作分組為動作群組](workflows-group-actions.md)。
# 將閘道新增至工作流程
在 Amazon CodeCatalyst 中，您可以將閘道新增至工作流程，以防止其繼續，除非符合特定條件。使用下列指示將閘道新增至工作流程。
如需閘道的詳細資訊，請參閱 [閘道工作流程執行](workflows-gates.md)。
**新增和設定閘道**
1. 開啟 CodeCatalyst 主控台，網址為 https：//[https://codecatalyst.aws/](https://codecatalyst.aws/)。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 選擇工作流程的名稱。您可以依定義工作流程的來源儲存庫或分支名稱進行篩選，或依工作流程名稱或狀態進行篩選。
1. 選擇**編輯**。
1. 選擇**視覺化**。
1. 在左側，選擇**閘道**。
1. 在閘道目錄中，搜尋閘道，然後選擇加號 (**＋**) 將閘道新增至工作流程。
1. 設定閘道。選擇**視覺化**以使用視覺化編輯器，或選擇 **YAML** 以使用 YAML 編輯器。如需詳細說明，請參閱：
+ [新增「核准」閘道](workflows-approval-add.md)
1. （選用） 選擇**驗證**以確保 YAML 程式碼有效。
1. 選擇**遞交**以遞交您的變更。
# 定序閘道和動作
在 Amazon CodeCatalyst 中，您可以設定要在工作流程動作、動作群組或閘道之前或之後執行的閘道。例如，您可以設定在`Deploy`動作之前執行的`Approval`閘道。在這種情況下，該`Deploy`動作被說是*取決於*`Approval`閘道。
若要設定閘道和動作之間的相依性，請設定閘道或動作的**相依**屬性。如需說明，請參閱 [在動作之間設定相依性](workflows-depends-on-set-up.md)。參考的指示是指工作流程*動作*，但同樣適用於閘道。
如需如何使用閘道設定**相依**屬性的範例，請參閱 [範例：「核准」閘道](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)新增至工作流程。*核准閘道*可防止工作流程繼續進行，直到使用者或一組使用者在 CodeCatalyst 主控台中提交一或多個核准。授予所有核准後，閘道會「解鎖」，並允許工作流程執行繼續。
在您的工作流程中使用**核准**閘道，讓您的開發、營運和領導團隊有機會在將您的變更部署到更廣泛的受眾之前檢閱變更。
如需工作流程執行的詳細資訊，請參閱 [執行工作流程](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**：必須提交必要的核准數量。所需的核准數量是可設定的，而且每個使用者都可以提交單一核准。
+ **條件 2**：所有核准都必須在閘道逾時之前提交。閘道會在啟用 14 天後逾時。此期間無法設定。
+ **條件 3**：沒有人必須拒絕工作流程執行。單一拒絕會導致工作流程執行失敗。
+ **條件 4**：（只有在您使用取代的執行模式時才適用。) 執行不得由稍後的執行取代。如需詳細資訊，請參閱[工作流程核准如何使用佇列、取代和平行執行模式？](#workflows-approval-run-mode)。
如果不符合任何條件，CodeCatalyst 會停止工作流程，並將執行狀態設定為**失敗** （在**條件 1** 到 **3** 的情況下） 或**被取代** （在**條件 4 **的情況下）。
## 何時使用「核准」閘道
一般而言，您會在工作流程中使用**核准**閘道，將應用程式和其他資源部署到生產伺服器或任何必須驗證品質標準的環境。透過在部署到生產環境之前放置 閘道，您可以讓檢閱者有機會在新軟體修訂版可供公開使用之前進行驗證。
## 誰可以提供核准？
任何身為您專案成員且具有**貢獻者**或**專案管理員**角色的使用者都可以提供核准。具有屬於您專案空間之**空間管理員**角色的使用者也可以提供核准。
**注意**
具有 **Reviewer** 角色的使用者無法提供核准。
## 如何通知使用者需要核准？
若要通知使用者需要核准，您必須：
+ 讓 CodeCatalyst 傳送 Slack 通知給他們。如需詳細資訊，請參閱[設定核准通知](workflows-approval-notify.md)。
+ 前往 CodeCatalyst 主控台中**核准**和**拒絕**按鈕所在的頁面，並將該頁面的 URL 貼到傳送給核准者的電子郵件或簡訊應用程式中。如需如何導覽至此頁面的詳細資訊，請參閱 [核准或拒絕工作流程執行](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)，則執行會在目前在閘道等待核准的執行後方排入佇列。當該閘道解除鎖定 （即所有核准都已授予） 時，佇列中的下一個執行會推進到閘道，並等待核准。此程序會繼續透過閘道one-by-one處理排入佇列的執行。 [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/zh_tw/codecatalyst/latest/userguide/images/flows/runmode-queued-ma.png)
**圖 2**：「超級執行模式」和**核准**閘道
![\[「核准」閘道如何與「更新後的執行模式」搭配使用\]](http://docs.aws.amazon.com/zh_tw/codecatalyst/latest/userguide/images/flows/runmode-superseded-ma.png)
**圖 3**：「平行執行模式」和**核准**閘道
![\[「核准」閘道如何與「平行執行模式」搭配使用\]](http://docs.aws.amazon.com/zh_tw/codecatalyst/latest/userguide/images/flows/runmode-parallel-ma.png)
# 範例：「核准」閘道
下列範例示範如何在兩個名為 的動作`Approval_01`之間新增名為 `Staging`的**核准**閘道，以及 `Production`。`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：//[https://codecatalyst.aws/](https://codecatalyst.aws/) 開啟 CodeCatalyst 主控台。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 選擇工作流程的名稱。您可以依定義工作流程的來源儲存庫或分支名稱進行篩選，或依工作流程名稱或狀態進行篩選。
1. 選擇**編輯**。
1. 在左上角，選擇**閘道**。
1. 在**閘道**目錄中的**核准**中，選擇加號 (**\$1**)。
1. 選擇**輸入**，然後在**相依**欄位中執行下列動作。
指定必須成功執行的動作、動作群組或閘道，才能執行此閘道。根據預設，當您將閘道新增至工作流程時，閘道會設定為取決於工作流程中的最後一個動作。如果您移除此屬性，閘道將不會相依於任何項目，而且 會在其他動作之前先執行。
**注意**
閘道必須設定為在動作、動作群組或閘道之前或之後執行。它無法設定為與其他動作、動作群組和閘道平行執行。
如需 **依功能而定**的詳細資訊，請參閱 [定序閘道和動作](workflows-gates-depends-on.md)。
1. 選擇 **Configuration** (組態) 索引標籤。
1. 在**閘道名稱**欄位中，執行下列動作。
指定您要提供閘道的名稱。所有閘道名稱在工作流程中必須是唯一的。閘道名稱僅限於英數字元 (a-z、A-Z、0-9)、連字號 (-) 和底線 (\$1)。不允許空格。您不能使用引號在閘道名稱中啟用特殊字元和空格。
1. （選用） 在**核准數量**欄位中，執行下列動作。
指定解鎖核准閘道所需的**最低核准**數量。最小值為 `1`。上限為 `2`。如果省略，則預設值為 `1`。
**注意**
如果您想要省略 `ApprovalsRequired` 屬性，請從工作流程定義檔案移除閘道的 `Configuration`區段。
1. （選用） 選擇**驗證**以在遞交之前驗證工作流程的 YAML 程式碼。
1. 選擇**遞交**，輸入遞交訊息，然後再次選擇**遞交**。
------
#### [ YAML ]
**將「核准」閘道新增至工作流程 (YAML 編輯器）**
1. 在 https：//[https://codecatalyst.aws/](https://codecatalyst.aws/) 開啟 CodeCatalyst 主控台。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 選擇工作流程的名稱。您可以依定義工作流程的來源儲存庫或分支名稱進行篩選，或依工作流程名稱或狀態進行篩選。
1. 選擇**編輯**。
1. 選擇 **YAML**。
1. 使用下列範例做為指南，新增 `Approval`區段和基礎屬性。如需詳細資訊，請參閱《[「核准」閘道 YAML](approval-ref.md)》中的 [工作流程 YAML 定義](workflow-reference.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. 選擇 **Save** (儲存)。
# 核准或拒絕工作流程執行
包含**核准**閘道的工作流程執行將需要核准或拒絕。使用者可以提供核准或拒絕，從：
+ CodeCatalyst 主控台
+ 團隊成員提供的連結
+ 自動化 Slack 通知
使用者提供核准或拒絕後，此決策將無法復原。
**注意**
只有特定使用者可以核准或拒絕工作流程執行。如需詳細資訊，請參閱[誰可以提供核准？](workflows-approval.md#workflows-approval-who)。
**開始之前**
請確定您已將**核准**閘道新增至工作流程。如需詳細資訊，請參閱[新增「核准」閘道](workflows-approval-add.md)。
**從 CodeCatalyst 主控台開始核准或拒絕工作流程執行**
1. 在 https：//[https://codecatalyst.aws/](https://codecatalyst.aws/) 開啟 CodeCatalyst 主控台。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 選擇工作流程的名稱。您可以依定義工作流程的來源儲存庫或分支名稱進行篩選，或依工作流程名稱或狀態進行篩選。
1. 在工作流程圖表中，選擇代表**核准**閘道的方塊。
側邊面板隨即出現。
**注意**
此時，您可以視需要將此頁面的 URL 傳送給其他核准者。
1. 在**檢閱決策**下，選擇**核准**或拒絕****。
1. （選用） 在**註解 - 選用**中，輸入註解，指出您核准或拒絕工作流程執行的原因。
1. 選擇**提交**。
**從團隊成員提供的連結開始核准或拒絕工作流程執行**
1. 選擇團隊成員傳送給您的連結。（您可以讓團隊成員閱讀上述程序以取得連結。)
1. 如果系統要求，請登入 CodeCatalyst。
系統會將您重新導向至工作流程執行核准頁面。
1. 在**檢閱決策**下，選擇**核准**或拒絕****。
1. （選用） 在**註解 - 選用**中，輸入註解，指出您核准或拒絕工作流程執行的原因。
1. 選擇**提交**。
**從自動化 Slack 通知開始核准或拒絕工作流程執行**
1. 確定已設定 Slack 通知。請參閱 [設定核准通知](workflows-approval-notify.md)。
1. 在 Slack 中，在傳送核准通知的管道中，選擇核准通知中的連結。
1. 如果系統要求，請登入 CodeCatalyst。
系統會將您重新導向至工作流程執行頁面。
1. 在工作流程圖表中，選擇核准閘道。
1. 在**檢閱決策**下，選擇**核准**或拒絕****。
1. （選用） 在**註解 - 選用**中，輸入註解，指出您核准或拒絕工作流程執行的原因。
1. 選擇**提交**。
# 「核准」閘道 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 會將它們排入佇列，並依啟動順序逐一處理。您可以指定*執行模式*來變更此預設行為。有幾種執行模式：
+ （預設） 佇列執行模式 – CodeCatalyst 程序會逐一執行
+ 取代的執行模式 – CodeCatalyst 程序會逐一執行，而較新的執行會覆寫較舊的執行
+ 平行執行模式 – 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) 說明在佇列執行模式中設定的工作流程。它顯示：
+ 七個執行透過工作流程運作。
+ 兩個佇列：一個在輸入來源的項目之外 (**Repo：main**)，另一個在 **BuildTestActionGroup** 動作的項目之外。
+ 兩個鎖定的區塊：輸入來源 (**Repo：main**) 和 **BuildTestActionGroup**。
以下是當工作流程執行完成處理時，實物會轉傳的方式：
+ 當 **Run-4d444** 完成來源儲存庫的複製時，它會結束輸入來源，並加入 **Run-3c333** 後面的佇列。然後，**Run-5e555** 將輸入輸入來源。
+ 當 **Run-1a111** 完成建置和測試時，它會結束 **BuildTestActionGroup** 動作並輸入 **DeployAction** 動作。然後，**Run-2b222** 將輸入 **BuildTestActionGroup** 動作。
**圖 1**：在「佇列執行模式」中設定的工作流程
![\[在「佇列執行模式」中設定的工作流程\]](http://docs.aws.amazon.com/zh_tw/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png)
在以下情況下使用佇列執行模式：
+ **您想要在功能和執行之間保持one-to-one的關係 – 使用取代模式時，這些功能可能會分組**。例如，當您在遞交 1 中合併功能 1 時，執行 1 會啟動，而當您在遞交 2 中合併功能 2 時，執行 2 會啟動，以此類推。如果您要使用取代模式而非佇列模式，您的功能 （和遞交） 將在取代其他功能的執行中分組在一起。
+ **您想要避免使用平行模式時可能發生的競爭條件和非預期問題**。例如，如果兩個軟體開發人員 Wang 和 Saanvi 開始工作流程大約同時執行以部署到 Amazon ECS 叢集，Wang 的執行可能會開始叢集上的整合測試，而 Saanvi 的執行則會將新的應用程式程式碼部署到叢集，導致 Wang 的測試失敗或測試錯誤的程式碼。另一個範例是，您可能有一個沒有鎖定機制的目標，在這種情況下，兩個執行可能會以非預期的方式覆寫彼此的變更。
+ **您想要限制 CodeCatalyst 用來處理執行之運算資源的負載**。 CodeCatalyst 例如，如果您的工作流程中有三個動作，您最多可以同時發生三個執行。對一次可發生的執行次數施加限制，可讓執行輸送量更可預測。
+ **您想要限制工作流程對第三方服務提出的請求數量**。例如，您的工作流程可能有建置動作，其中包含從 Docker Hub 提取映像的指示。[Docker Hub 會將您可以提出的提取請求數量限制](https://www.docker.com/increase-rate-limits)為每個帳戶每小時特定數量，如果您超過限制，將會鎖定您。使用排入佇列的執行模式來減慢您的執行輸送量，將產生每小時對 Docker Hub 的較少請求，從而限制鎖定和導致建置和執行失敗的可能性。
**佇列大小上限**：50
**佇列大小上限**的注意事項：
+ 最大佇列大小是指工作流程中*所有佇列*允許的執行次數上限。
+ 如果佇列的執行時間超過 50 次，則 CodeCatalyst 會捨棄第 51 次和後續的執行。
**失敗行為**：
如果執行在動作處理時變得沒有回應，則其後面的執行會保留在佇列中，直到動作逾時為止。動作在一小時後逾時。
如果 動作內的執行失敗，則允許其後方的第一個佇列執行繼續。
## 關於取代的執行模式
*取代的執行模式*與排入*佇列的執行模式*相同，但：
+ 如果佇列的執行追上佇列中的另一個執行，則稍後的執行會取代 （接管） 較早的執行，而較早的執行會取消並標示為 'upersed'。
+ 做為第一個項目符號中所述行為的結果，佇列只能在使用取代的執行模式時包含一次執行。
使用 中的工作流程[Figure 1](#figure-1-workflow-queued-run-mode)做為指南，將取代的執行模式套用至此工作流程將導致下列情況：
+ **Run-7g777** 會取代佇列中的其他兩個執行，並且會是**佇列 \$11** 中剩餘的唯一執行。**Run-6f666** 和 **Run-5e555** 將會取消。
+ **Run-3c333** 會取代 **Run-2b222**，並且是**佇列 \$12** 中剩餘的唯一執行。**Run-2b222** 將被取消。
如果您想要的話，請使用取代的執行模式：
+ 比使用佇列模式的輸送量更好
+ 與排入佇列模式相比，對第三方服務的請求更少；如果第三方服務具有速率限制，例如 Docker Hub，這就很有幫助
## 關於平行執行模式
在*平行執行模式中*，執行彼此獨立，且不會等待其他執行完成再開始。沒有佇列，且執行輸送量只會受到工作流程內動作完成的速度限制。
在開發環境中使用平行執行模式，其中每個使用者都有自己的功能分支，並部署到其他使用者未共用的目標。
**重要**
如果您有多個使用者可以部署的共用目標，例如生產環境中的 Lambda 函數，請勿使用平行模式，因為可能會導致競爭條件。當平行工作流程執行嘗試同時變更共用資源，導致無法預測的結果時，就會發生*競爭條件*。
**平行執行的最大數量**：每個 CodeCatalyst 空間 1000 個
## 設定執行模式
您可以將執行模式設定為已排入佇列、已取代或平行。預設值已排入佇列。
當您將執行模式從佇列或取代變更為平行時，CodeCatalyst 會取消已佇列的執行，並允許動作目前正在處理的執行完成，然後再取消它們。
當您將執行模式從平行變更為佇列或取代時，CodeCatalyst 會讓目前執行的所有平行執行完成。您在將執行模式變更為已排入佇列或已取代後啟動的任何執行都會使用新的模式。
------
#### [ Visual ]
**使用視覺化編輯器變更執行模式**
1. 開啟 CodeCatalyst 主控台，網址為 https：//[https://codecatalyst.aws/](https://codecatalyst.aws/)。
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. 開啟 CodeCatalyst 主控台，網址為 https：//[https://codecatalyst.aws/](https://codecatalyst.aws/)。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 選擇工作流程的名稱。您可以依定義工作流程的來源儲存庫或分支名稱進行篩選，或依工作流程名稱或狀態進行篩選。
1. 選擇**編輯**。
1. 選擇 **YAML**。
1. 新增 `RunMode` 屬性，如下所示：
```
Name: Workflow_6d39
SchemaVersion: "1.0"
RunMode: QUEUED|SUPERSEDED|PARALLEL
```
如需詳細資訊，請參閱《》中 [最上層屬性](workflow-reference.md#workflow.top.level) 區段的 `RunMode` 屬性描述[工作流程 YAML 定義](workflow-reference.md)。
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`和 的多個快取進行快取的範例 YAML 程式碼片段`cacheKey2`。
```
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 會套用快取存取限制，以確保某個工作流程中的動作無法修改來自不同工作流程的快取。這可保護每個工作流程，避免其他工作流程推送可能影響建置或部署的不正確資料。快取範圍會強制執行限制，將快取隔離到每個工作流程和分支配對。例如， `workflow-A` 分支`feature-A`中的檔案快取與 同級分支 `workflow-A`中的檔案快取不同`feature-B`。
當工作流程尋找指定的檔案快取且找不到它時，就會發生快取遺漏。這可能有多種原因，例如建立新分支或參考新快取且尚未建立時。也可能在快取過期時發生，依預設，會在上次使用後 14 天發生。為了減輕快取遺漏並提高快取命中率，CodeCatalyst 支援備用快取。備用快取是替代快取，提供還原部分快取的機會，這可能是快取的較舊版本。快取會先在 下搜尋屬性名稱`FileCaching`的相符項目來還原，如果找不到， 會評估 `RestoreKeys`。如果屬性名稱和所有 都存在快取遺漏`RestoreKeys`，工作流程將繼續執行，因為快取是盡最大努力且不保證的。
## 建立快取
您可以使用下列指示將快取新增至工作流程。
------
#### [ Visual ]
**使用視覺化編輯器新增快取**
1. 開啟 CodeCatalyst 主控台，網址為 https：//[https://codecatalyst.aws/](https://codecatalyst.aws/)。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 選擇工作流程的名稱。您可以依定義工作流程的來源儲存庫或分支名稱進行篩選，或依工作流程名稱或狀態進行篩選。
1. 選擇**編輯**。
1. 選擇**視覺化**。
1. 在工作流程圖表中，選擇您要新增快取的動作。
1. 選擇 **Configuration (組態)**。
1. 在**檔案快取 - 選用**下，選擇**新增快取**並在欄位中輸入資訊，如下所示：
**索引鍵**
指定主要快取屬性名稱的名稱。快取屬性名稱在工作流程中必須是唯一的。每個動作在 中最多可以有五個項目`FileCaching`。
**路徑**
指定快取的關聯路徑。
**還原金鑰 - 選用**
找不到主要快取屬性時，指定要用作備用的還原金鑰。還原金鑰名稱在工作流程中必須是唯一的。每個快取在 中最多可以有五個項目`RestoreKeys`。
1. （選用） 選擇**驗證**以在遞交之前驗證工作流程的 YAML 程式碼。
1. 選擇**遞交**，輸入遞交訊息，然後再次選擇**遞交**。
------
#### [ YAML ]
**使用 YAML 編輯器新增快取**
1. 在 https：//[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`。
+ 每個快取在 中最多可以有五個項目`RestoreKeys`。
以下是路徑的限制：
+ 不允許星號 (\$1)。
+ 路徑最多可有 255 個字元。
# 檢視工作流程執行狀態和詳細資訊
在 Amazon CodeCatalyst 中，您可以檢視單一工作流程執行的狀態和詳細資訊，或同時檢視多個執行。
如需可能執行狀態的清單，請參閱 [工作流程執行狀態](workflows-view-run-status.md)。
**注意**
您也可以檢視工作流程狀態，這與工作流程*執行*狀態不同。如需詳細資訊，請參閱[檢視工作流程的狀態](workflows-view-status.md)。
如需工作流程執行的詳細資訊，請參閱 [執行工作流程](workflows-working-runs.md)。
**Topics**
+ [檢視單一執行的狀態和詳細資訊](#workflows-view-run-single)
+ [檢視專案中所有執行的狀態和詳細資訊](#workflows-view-run-all)
+ [檢視特定工作流程所有執行的狀態和詳細資訊](#workflows-view-run-wf)
+ [在工作流程圖表中檢視工作流程的執行](#workflows-view-run-wf-diagram)
## 檢視單一執行的狀態和詳細資訊
您可能想要檢視單一工作流程執行的狀態和詳細資訊，以檢查其是否成功、查看何時完成，或檢視啟動的人員或項目。
**檢視單一執行的狀態和詳細資訊**
1. 在 https：//[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：//[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：//[https://codecatalyst.aws/](https://codecatalyst.aws/) 開啟 CodeCatalyst 主控台。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 選擇工作流程的名稱。您可以依定義工作流程的來源儲存庫或分支名稱進行篩選，或依工作流程名稱或狀態進行篩選。
1. 在工作流程的名稱下，選擇**執行**。
與所選工作流程相關聯的執行隨即出現。
頁面分為兩個部分：
+ **作用中執行** – 顯示正在進行的執行。這些執行將處於下列其中一種狀態：**進行中**。
+ **執行歷史記錄** – 顯示已完成的執行 （即未進行）。
如需執行狀態的詳細資訊，請參閱 [工作流程執行狀態](workflows-view-run-status.md)。
## 在工作流程圖表中檢視工作流程的執行
您可以在工作流程一起進行時，檢視工作流程所有執行的狀態。執行會顯示在工作流程圖表中 （而不是在清單檢視中）。這可讓您以視覺化方式呈現哪些執行正在由哪些動作處理，以及哪些執行正在佇列中等待。
**檢視多個執行在工作流程中一起進行時的狀態**
**注意**
此程序僅適用於您的工作流程使用佇列或取代的執行模式。如需詳細資訊，請參閱[設定執行的佇列行為](workflows-configure-runs.md)。
1. 在 https：//[https://codecatalyst.aws/](https://codecatalyst.aws/) 開啟 CodeCatalyst 主控台。
1. 選擇您的專案。
1. 在導覽窗格中，選擇 **CI/CD**，然後選擇**工作流程**。
1. 選擇工作流程的名稱。您可以依定義工作流程的來源儲存庫或分支名稱進行篩選，或依工作流程名稱或狀態進行篩選。
**注意**
請務必查看工作流程頁面，而不是執行頁面。
1. 選擇左上角**的最新狀態**索引標籤。
工作流程圖表隨即出現。
1. 檢閱工作流程圖表。圖表顯示工作流程中目前正在進行的所有執行，以及已完成的最新執行。更具體地說：
+ 在**來源**排入佇列並等待啟動之前，出現在頂端的執行。
+ 動作之間出現的執行會排入佇列，並等待下一個動作處理。
+ 動作中出現的執行為 1. 動作目前正在處理中、2. 動作已完成處理，或 3. 動作未處理 （通常是因為先前的動作失敗）。