亚马逊 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://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**运行**。 # 使用触发器自动启动工作流运行 您可以使用 CodeCatalyst 工作流程触发器自动启动 Amazon 工作流程。 *工作流触发器*简称*触发器*，使您可以在发生某些事件（例如代码推送）时自动启动工作流运行。您可能需要配置触发器，使软件开发人员不必通过 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) + [示例：一个简单的“push to main”触发器](#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` 时才启动工作流运行，请参阅[示例：一个简单的“push to main”触发器](#workflows-add-trigger-examples-push-main)。 ## 示例：一个简单的“push to main”触发器 以下示例显示了一个触发器，在代码被推送到源存储库中的 `main` 分支（而且*仅在*推送到 `main` 分支）时，该触发器将启动工作流运行。 ``` Triggers: - Type: PUSH Branches: - main ``` ## 示例：一个简单的拉取请求触发器 以下示例显示了一个触发器，在源存储库中创建或修订了任何拉取请求时，该触发器将启动工作流运行。 *激活此触发器后，使用工作流程定义文件和您要提取的分支（即源分支）中的其他源文件 CodeCatalyst 启动工作流程运行。* 例如，如果您使用名为的源分支`feature-123`和名为的目标分支创建拉取请求`main`，则使用工作流定义文件和其他源文件 CodeCatalyst 启动工作流程运行。`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）启动工作流运行的触发器。 激活此触发器后，使用`main`分支中的文件 CodeCatalyst 启动工作流程运行，然后为以开头的每个分支开始额外运行`release-`。 例如，如果您的源存储库中有名为`main``release-v1``bugfix-1`、、和`bugfix-2`的分支，则会 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 ``` ## 示例：带有拉取、分支和“CLOSED”事件的触发器 以下示例演示了一个触发器，每当有人对以 `main` 开头的分支关闭拉取请求时，该触发器就会启动工作流运行。 在本示例中： + 当您关闭对以 `main` 开头的目标分支的拉取请求时，就会自动启动工作流运行，该工作流将使用（现已关闭）源分支中的工作流定义文件和其他源文件。 + 如果您已将源存储库配置为在合并拉取请求后自动删除分支，则这些分支将永远没有机会进入 `CLOSED` 状态。这意味着合并的分支不会激活拉取请求 `CLOSED` 触发器。在这种情况下，激活 `CLOSED` 触发器的唯一方法是关闭拉取请求而不合并。 ``` Triggers: - Type: PULLREQUEST Branches: - main.* Events: - CLOSED ``` ## 示例：带有推送、分支和文件的触发器 以下示例演示了一个触发器，每当对 `main` 分支上的 `filename.txt` 文件或 `src` 目录中的任何文件进行更改时，该触发器就会启动工作流运行。 激活此触发器后，使用`main`分支中的工作流定义文件和其他源文件 CodeCatalyst 启动工作流程运行。 ``` 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：**对于推送和拉取请求触发器，如果要指定分支，您必须在触发器配置中指定目标（即“至”）分支。切勿指定源（即“自”）分支。 在以下示例中，从任何分支推送至 `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` 中的文件运行。（但是，如果您在 `main` 中创建 `test` 分支，则工作流将使用 `test` 中的文件运行。） 请查看**准则 3** 以了解原因。 # 添加触发器到工作流 按照以下说明在您的 Amazon CodeCatalyst 工作流程中添加推送、拉取或计划触发器。 有关触发器的更多信息，请参阅[使用触发器自动启动工作流运行](workflows-add-trigger.md)。 ------ #### [ Visual ] **添加触发器（可视化编辑器）** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 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` 事件的行为不太好说明，最好通过一个例子来理解。请参阅[示例：带有拉取、分支和“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 表达式，用于描述您希望何时执行计划的工作流运行。 中的 Cron 表达式 CodeCatalyst 使用以下六字段语法，其中每个字段用空格分隔： *minutes* *hours* *days-of-month* *month* *days-of-week* *year* **cron 表达式示例** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/codecatalyst/latest/userguide/workflows-add-trigger-add.html) 在中指定 cron 表达式时 CodeCatalyst，请务必遵循以下准则： + 为每个 `SCHEDULE` 触发器指定一个 cron 表达式。 + 在 YAML 编辑器中，将 cron 表达式用双引号（`"`）括起来。 + 使用协调世界时（UTC）格式指定时间。不支持其他时区。 + 两次运行之间应至少配置 30 分钟的运行间隔。不支持更快的节奏。 + 指定*days-of-month*或字*days-of-week*段，但不能同时指定两者。如果您在其中一个字段中指定值或星号（`*`），则必须在另一个字段中使用问号（`?`）。星号表示“全部”，问号表示“任何”。 有关 cron 表达式的更多示例以及有关通配符（如`?`、和）的信息 `*``L`，请参阅《*亚马逊 EventBridge *用户指南[》中的 Cron 表达式参考](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html)。 EventBridge 和中的 Cron 表达式 CodeCatalyst 的工作方式完全相同。 有关计划触发器的示例，请参阅[示例：工作流中的触发器](workflows-add-trigger-examples.md)。 **分支**和**分支模式** （可选） 指定触发器监控的源存储库中的分支，以便知道何时启动工作流运行。您可以使用正则表达式模式来定义分支名称。例如，使用 `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. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 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. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择**可视化**。 1. 在工作流图表中选择**源**框。 1. 在**触发器**下，选择垃圾桶图标以将 `Triggers` 部分从工作流中删除。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ #### [ YAML ] **删除“触发器”部分（YAML 编辑器）** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择 **YAML**。 1. 找到 `Triggers` 部分并将其删除。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ # 停止工作流运行 使用以下过程停止正在进行的工作流运行。如果您意外启动了运行，则可能需要停止运行。 停止工作流程运行时， CodeCatalyst 等待正在进行的操作完成，然后才会在控制台中将运行标记为 “**已停止**” CodeCatalyst 。任何还没有机会启动的操作都不会启动，而且会被标记为**已放弃**。 **注意** 如果运行已排队（也就是说，没有正在进行的操作），则运行将立即停止。 有关工作流运行的更多信息，请参阅[运行工作流](workflows-working-runs.md)。 **停止工作流运行** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 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)。 ## 我可以设置阶段门与其他操作并行运行吗？ 不能。阶段门只能在操作之前或之后运行。有关更多信息，请参阅[按顺序执行阶段门和操作](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 中，您可以将某个阶段门设置为在工作流操作、操作组或阶段门之前或之后运行。例如，您可以将 `Approval` 阶段门设置为在 `Deploy` 操作之前运行。在这种情况下，`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** 的情况下）。 ## 何时使用“批准”阶段门 通常，在工作流将应用程序和其他资源部署到生产服务器或任何必须验证质量标准的环境中时，您可以在工作流中使用**批准**阶段门。通过在部署到生产环境之前放置阶段门，您向审阅者提供了机会，在新的软件修订版面向公众发布之前对其进行验证。 ## 谁可以提供批准？ 任何用户，只要是您的项目的成员且具有**贡献者**或**项目管理员**角色，就可以提供批准。具有**空间管理员**角色且属于您的项目空间的用户也可以提供批准。 **注意** 具有**审阅者**角色的用户无法提供批准。 ## 如何通知用户需要该用户的批准？ 要通知用户需要该用户的批准，您必须： + 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_cn/codecatalyst/latest/userguide/images/flows/runmode-queued-ma.png) **图 2**：“取代运行模式”和**批准**阶段门 ![\[“批准”阶段门如何与“取代运行模式”配合使用\]](http://docs.aws.amazon.com/zh_cn/codecatalyst/latest/userguide/images/flows/runmode-superseded-ma.png) **图 3**：“并行运行模式”和**批准**阶段门 ![\[“批准”阶段门如何与“并行运行模式”配合使用\]](http://docs.aws.amazon.com/zh_cn/codecatalyst/latest/userguide/images/flows/runmode-parallel-ma.png) # 示例：“批准”阶段门 以下示例说明如何在名为 `Staging` 和 `Production` 的两个操作之间添加一个名为 `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. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 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. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 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. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 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_cn/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png) 在以下情况下使用排队运行模式： + **您希望在功能和运行之间保持一对一的关系，在使用取代模式时，这些功能可能会被分组**。例如，当您在提交 1 中合并功能 1 时，运行 1 会启动；当您在提交 2 中合并功能 2 时，运行 2 会启动，依此类推。如果您使用取代模式而不是排队模式，则您的功能（和提交）将一起分组到运行中，并会取代其他运行。 + **您需要避免使用并行模式时可能出现的争用情况和意外问题**。例如，如果有两位软件开发人员 Wang 和 Saanvi，他们在大致相同的时间启动工作流运行以部署到 Amazon ECS 集群，那么 Wang 的运行可能会在集群上启动集成测试，而 Saanvi 的运行会向集群部署新的应用程序代码，从而导致 Wang 的测试失败或测试了错误的代码。再举一个例子，您的目标可能没有锁定机制，在这种情况下，两次运行可能会以意想不到的方式覆盖彼此的更改。 + **您想限制 CodeCatalyst 用于处理运行的计算资源上的负载**。例如，如果工作流中有三个操作，则您最多可能会同时进行三个运行。通过对一次可以进行的运行数施加限制，可以使运行吞吐量更具可预测性。 + **您想限制工作流向第三方服务发出的请求数量**。例如，您的工作流可能有一个构建操作，其中包括从 Docker Hub 提取映像的说明。[Docker Hub 对每个账户每小时可以发出的拉取请求数量](https://www.docker.com/increase-rate-limits)有一定的限制，在超过限制时会被阻止。使用排队运行模式可降低运行吞吐量，这样就可以减少每小时向 Docker Hub 发出的请求数，从而避免可能出现的锁定情况以及导致的构建和运行失败。 **最大队列大小**：50 有关**最大队列大小**的注意事项： + 最大队列大小是指在工作流的*所有队列*中，允许的运行的最大数量。 + 如果队列中的运行超过 50 个，则 CodeCatalyst 会丢弃第 51 个及随后的运行。 **失败行为**： 如果某个运行在操作处理时变得没有响应，则其后面的运行将暂停在队列中，直到操作超时。操作在 1 小时后超时。 如果运行在操作内部失败，则允许排队在其后面的第一个运行继续进行。 ## 关于取代运行模式 *取代运行模式*与*排队运行模式*大致相同，不同之处在于： + 如果排队的运行赶上了队列中的另一个运行，则后一个运行将取代（接管）先前的运行，而先前的运行将被取消并标记为“取代”。 + 作为第一个要点中描述的行为的结果，使用取代运行模式时，队列只能包含一个运行。 以[Figure 1](#figure-1-workflow-queued-run-mode) 中的工作流为指南，对此工作流应用取代运行模式将导致以下结果： + **Run-7g777** 将取代队列中的另外两个运行，并且将是 **Queue \$11** 中唯一剩下的运行。**Run-6f666** 和 **Run-5e555** 将被取消。 + **Run-3c333** 将取代 **Run-2b222**，成为 **Queue \$12** 中唯一剩下的运行。**Run-2b222** 将被取消。 在有以下需求时，请使用取代运行模式： + 比排队模式更好的吞吐量 + 相比排队模式向第三方服务发出更少的请求；如果第三方服务有速率限制（例如 Docker Hub），这将非常有利 ## 关于并行运行模式 在*并行运行模式*中，运行是相互独立的，不会等待其他运行完成后才开始。其中没有队列，运行吞吐量仅受工作流内部的操作完成速度的限制。 在开发环境中使用并行运行模式，每个用户都有自己的功能分支，并部署到不与其他用户共享的目标。 **重要** 如果您有多个用户可以部署到的共享目标，例如生产环境中的 Lambda 函数，请不要使用并行模式，因为可能会导致争用情况。当并行工作流运行尝试同时更改共享资源时，就会出现*争用情况*，导致不可预测的结果。 **最大并行运行数量**：每个 CodeCatalyst 空间 1000 个 ## 配置运行模式 您可以将运行设置为排队、取代或并行模式。默认使用排队模式。 当您将运行从排队或取代模式更改为并行模式时，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. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 选择**编辑**。 1. 选择**可视化**。 1. 在工作流图表中，选择要添加缓存的操作。 1. 选择**配置**。 1. 在**文件缓存 – 可选**下，选择**添加缓存**，然后在字段中输入信息，如下所示： **键** 指定主缓存属性的名称。缓存属性名称在您的工作流内必须是唯一的。每个操作在 `FileCaching` 中最多可以有五个条目。 **路径** 为您的缓存指定关联路径。 **恢复键 – 可选** 指定在找不到主缓存属性时用作回退手段的恢复键。恢复键名称在您的工作流内必须是唯一的。每个缓存在 `RestoreKeys` 中最多可以有五个条目。 1. （可选）选择**验证**，在提交之前验证工作流的 YAML 代码。 1. 选择**提交**，输入提交消息，然后再次选择**提交**。 ------ #### [ YAML ] **使用 YAML 编辑器添加缓存** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 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. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 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. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 在**工作流**下，选择**运行**。 此时将显示项目中所有存储库的所有分支中的所有工作流的所有运行。 页面中包括以下列： + **ID** – 运行的唯一标识符。选择运行 ID 链接以查看有关运行的详细信息。 + **状态** – 工作流运行的处理状态。有关运行状态的更多信息，请参阅[工作流运行状态](workflows-view-run-status.md)。 + **触发器** – 启动工作流运行的人员、提交、拉取请求（PR，Pull Request）或计划。有关更多信息，请参阅[使用触发器自动启动工作流运行](workflows-add-trigger.md)。 + **工作流** – 启动运行的工作流的名称，以及工作流定义文件所在的源存储库和分支。您可能需要展开列宽才能看到此信息。 **注意** 如果此列设置为**不可用**，则通常是因为关联的工作流已删除或已移动。 + **开始时间** – 工作流运行的启动时间。 + **持续时间** – 处理工作流运行所花费的时间。持续时间过长或过短都可能表示存在问题。 + **结束时间** – 工作流运行的结束时间。 ## 查看特定工作流所有运行的状态和详细信息 您可能需要查看与特定工作流关联的所有运行的状态和详细信息，以查看是否有任何运行在工作流中造成瓶颈，或者查看哪些运行当前正在进行或已完成。 **查看特定工作流的所有运行的状态和详细信息** 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 1. 在工作流的名称下，选择**运行**。 将显示与所选工作流关联的运行。 此页面分为两个部分： + **活跃运行** – 显示正在进行的运行。这些运行将处于以下状态：**进行中**。 + **运行历史记录** – 显示已完成（即不在进行中）的运行。 有关运行状态的更多信息，请参阅[工作流运行状态](workflows-view-run-status.md)。 ## 在工作流图表中查看工作流的运行 当多个运行一起在工作流中执行时，您可以查看工作流中所有运行的状态。运行结果显示在工作流图表中（而不是列表视图）。图表直观地显示哪些运行正在由哪些操作处理，哪些运行正在队列中等待。 **查看多个运行在工作流中一起执行的状态** **注意** 仅当您的工作流使用排队或取代运行模式时，此过程才适用。有关更多信息，请参阅 [配置运行的排队行为](workflows-configure-runs.md)。 1. 打开 CodeCatalyst 控制台，[网址为 https://codecatalyst.aws/](https://codecatalyst.aws/)。 1. 选择您的项目。 1. 在导航窗格中，选择 **CI/CD**，然后选择**工作流**。 1. 选择工作流的名称。您可以按定义工作流的源存储库或分支名称筛选，也可以按工作流名称或状态筛选。 **注意** 确保您查看的是工作流页面，而不是运行页面。 1. 选择左上角的**最新状态**选项卡。 此时将出现工作流图表。 1. 查看工作流图表。图表显示工作流中当前正在进行的所有运行，以及已完成的最新运行。更具体地说： + 显示在顶部，位于**源**之前的运行在排队等待启动。 + 显示在操作之间的运行在排队，等待由下一个操作处理。 + 在操作中显示的运行的状态是 1. 当前正在由该操作处理，2. 该操作已完成处理，或者 3. 未由该操作处理（通常是因为之前的操作失败）。