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

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 代码和包含文档文件 的文档 子文件夹。当任何人更改部署文件夹中的任何 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 可确保在开始新运行之前等待任何活动工作流运行完成。