使用触发器控制工作流的运行时间

5 分钟

现在你已经创建了一个可将 Bicep 文件部署到 Azure 环境的工作工作流。但是，无论何时更改文件，都必须手动运行工作流。在本单元中，你将了解如何在 Bicep 代码发生更改时触发工作流的自动运行。

注意

本单元中显示的命令用于说明概念。请暂时不要运行这些命令。稍后你将练习在此处学到的知识。

什么是工作流触发器？

工作流触发器是一种条件，满足此条件时，会基于你创建的规则自动运行工作流。你可以将触发器设置为按计划的时间间隔运行工作流。还可以将触发器设置为每次在存储库中的文件发生更改时运行工作流。你可以选择第二个选项，因为每次更改代码时都运行所有测试和部署步骤是很好的做法。

如果不使用自动触发器，可能有人会更改 Bicep 文件，甚至将其提交并推送到存储库，但如果忘记运行工作流，Bicep 文件中的资源定义会与部署到 Azure 环境的资源的定义之间产生差异。假设已完成了几个提交和推送，但尚未部署。如果有人在其中一项更改中引入了 Bicep 文件中的错误或错误配置，可能很难在稍后部署的多个提交中跟踪这些错误。经过一段时间后，你将不再相信你的 Bicep 代码真实反映了你的基础结构，其价值会降低。

如果将工作流设置为在每次更新文件时运行，那么，在推送更改的那一刻，工作流就开始运行了。你可以获得有关更改有效性的即时反馈，并可确保你的生产环境始终是最新的。

推送事件触发器

常见的触发器类型为推送事件触发器，也称为连续集成触发器或 CI 触发器。当你使用推送事件触发器时，每次对特定分支进行更改时，工作流都会运行。如果提交更改并将其推送到其他分支，则不会触发工作流，工作流将不会运行。对于默认或主分支，通常使用此类型的触发器，并使用以下代码：

on:
  push:
    branches:
      - main

当多个分支更改时触发

可以设置触发器，以在特定的分支或分支集上运行工作流。例如，假设创建了发布分支，其中包含将为项目的特定版本部署的代码。可以使用 release/v1、release/v2 等分支名称。你希望每当代码在以名称 release/ 开头的分支上发生更改时都运行工作流。可以使用 ** 通配符：

on:
  push:
    branches:
      - main
      - 'release/**'

此外，还可以排除特定分支。假设你正在与项目的团队成员合作。你的同事创建了功能分支以在 Bicep 文件中验证他们的想法。所有功能分支均采用 feature/add-database、feature/improve-performance 这类命名方式。你希望在同事创建的功能分支以外的其他所有分支上自动运行工作流。通过使用 exclude 属性，可以确保工作流不会因功能分支的更改而自动触发：

on:
  push:
    branches-ignore:
      - 'feature/**'

备注

可以使用 ! 字符排除特定分支。假设你希望为主分支和所有发布分支（alpha 版本除外）触发工作流。可以使用 ! 字符来表示：

on:
  push:
    branches:
      - main
      - 'release/**'
      - '!release/**-alpha'

不能在一个触发器中同时使用 branches 和 branches-ignore，因此 ! 字符使你可以灵活地控制触发器的行为。

路径筛选器

有时，存储库中会有与部署无关的文件。例如，在存储库中，你可能有一个包含 Bicep 代码的 deploy 文件夹和一个包含文档文件的 docs 子文件夹。你希望每当有人更改 deploy 文件夹中的任何 Bicep 文件时，系统都会触发工作流，但不希望在有人仅更改文档文件时触发工作流。若要设置触发器来响应存储库中特定文件夹的更改，可以使用路径筛选器：

on:
  push:
    paths:
      - 'deploy/**'
      - '!deploy/docs/**'

如果有人提交仅更新某个文档文件的更改，工作流不会运行。但是，如果有人更改了 Bicep 文件，或者除了更改文档文件之外还更改了 Bicep 文件，触发器会运行工作流。

备注

你还可以使用 paths-ignore，它的工作方式类似于 branches-ignore 关键字。但是，不能在同一触发器中使用 paths 和 paths-ignore。

安排工作流自动运行

可以按设定的计划运行工作流，而不是为了响应文件更改而运行工作流。例如，你可能每晚运行一次 Bicep 代码发布，或者每天早上自动部署一个测试环境。使用 schedule 关键字，并使用 cron 表达式设置频率：

on:
  schedule:
    - cron: '0 0 * * *'

备注

cron 表达式是一种特殊格式的字符序列，用于指定某事件发生的频率。在本例中，0 0 * * * 表示每天在 UTC 午夜时间运行。

在 YAML 文件中，需要在包含 * 字符（如 cron 表达式）的字符串两边添加引号。

计划事件始终在存储库的默认分支上运行工作流。

使用多个触发器

可以结合使用触发器和计划，如以下示例中所示：

on:
  push:
    branches:
      - main
  schedule:
    - cron: '0 0 * * *'

如果在同一工作流中创建分支触发器和计划触发器，则每次在触发器中设置的分支和设置的计划中的文件发生更改时，都将运行该工作流。在本例中，工作流会在每天 UTC 午夜时间运行，还会在将更改推送到主分支时运行。

提示

为每个工作流设置触发器是一种很好的做法。如果不设置触发器，则默认情况下，只要任何分支上的任何文件发生更改，工作流就会自动运行，而这并不是你所希望的。

Webhook 触发器

GitHub 还提供 Webhook 事件，当存储库中发生某些事件时，它会自动运行。这些事件包括有人创建了一个分支，对 GitHub 问题的更新，或对拉取请求的更改。通常，这些事件不需要运行 Bicep 部署工作流，但你可以改为运行其他自动化操作。

并发控制

默认情况下，GitHub Actions 允许工作流的多个实例同时运行。如果在短时间内对分支进行多次提交，或者在计划下一个触发时，上一个运行未完成，则会发生这种情况。

在某些情况下，有多个并发运行的工作流不是问题。但在使用部署工作流时，可能会很难确保工作流的运行不会以意想不到的方式覆盖 Azure 资源或配置。

若要避免这些问题，可以应用并发控制。使用 concurrency 关键字，然后指定一个在工作流的所有运行中保持一致的字符串。它通常是硬编码的字符串，如以下示例所示：

concurrency: MyWorkflow

然后 GitHub Actions 确保在开始新运行之前，它会等待所有活动的工作流运行完成。