了解拉取请求验证
使用拉取请求时，你可以确保由其他人来评审对 Azure 部署的任何更新。 不过，对代码变更运行自动检查也很有帮助。 在此单元中，你将了解如何使用自动拉取请求验证和检查来提高团队对代码变更的信心。
拉取请求验证
评审 Bicep 代码的拉取请求时，你可能会遇到一些用于评估更改的常见步骤。 这些步骤可能包括：
- 检查 Bicep 文件是否有任何错误或 linter 警告。
- 确保 Bicep 文件中以前定义的任何资源都可以继续使用。
- 测试任何新定义的资源，以确保它们成功部署，并按预期运行。
“拉取请求验证”涉及到自动执行其中某些活动。 当你自动执行拉取请求检查时，审阅者可以将他们的时间花在其他重要的评审步骤上，如确保代码满足团队质量标准并实现业务目标。
在 GitHub Actions 工作流中，可以将触发器定义为在拉取请求过程中的特定点（包括创建、更新、合并或关闭拉取请求时）调用工作流。
在拉取请求验证工作流中测试 Bicep 代码
在以前的模块中，你已了解如何为 Lint 分析、验证、部署和测试 Azure 基础结构更改（包括跨多个环境）构建复杂的 GitHub Actions 工作流。 这些工作流在你将变更合并到主分支后运行。
你还可以在拉取请求验证工作流中运行多个相同的活动。 例如：
- 对 Bicep 代码进行“Lint 分析”可帮助确保代码的语义正确，且代码遵循某些基线推荐的 Bicep 做法。
- “预检验证”可帮助你满怀信心地成功部署代码，而无需实际部署文件。 根据资源类型，预检验证可能会查找无效资源名称、特定资源的无效区域以及是否指定了无法成功部署的配置等问题。
- “What-if”，它列出了部署后将对 Azure 环境所做的更改。
- “部署”，实际部署资源并确保没有部署错误。
- 部署后测试资源，以确保根据业务要求对其进行配置。
拉取请求验证工作流是正常的 GitHub Actions 工作流，因此它可以运行任何这些任务。 但是，有必要考虑一下在拉取请求中有意义地运行的检查类型。 上面列出的许多验证活动都需要访问 Azure 环境。 例如，What-if 操作将 Bicep 文件中定义的资源与 Azure 订阅中的资源进行比较。 针对生产环境运行此比较很有意义，但如果工作流是专门为尚未完成或合并的代码设计的，你可能不太愿意从该工作流针对生产环境运行操作，因为这会带来一些额外的风险。
在此模块中，你将向拉取请求验证工作流添加两种检查：
- 对 Bicep 代码执行 Lint 分析，以对其运行一组初始检查。
- 将代码部署到全新的临时环境。
这两个活动不需要连接到生产 Azure 环境，甚至不需要连接到任何常规的非生产环境（如测试、QA 或暂存）。 通过运行这两个活动，你仍可以在代码更改中建立良好的置信度，以便可以将它们合并到存储库的主分支中。
这些检查对审阅者很有用，因为这些检查为他们节省了手动运行活动所需的时间。 这些检查对作为拉取请求作者的你也很有用，因为你可以使用这些检查来初步了解更改在稍后的部署过程中的工作原理。
在你自己的拉取请求验证工作流中，你可以选择将验证检查与其他活动一起扩展。
拉取请求生命周期触发器
GitHub 中的拉取请求可以经历许多不同的“生命周期事件”。 例如，“打开”拉取请求。 然后，作者可能会将更改推送到源分支（同步），这会影响拉取请求的内容。 接下来，可以合并拉取请求、关闭拉取请求而不进行合并，甚至可以在以后重新打开。
借助 GitHub Actions，你可以定义响应任何这些事件的“工作流触发器”。 例如，可以定义这样一个工作流，即在打开、同步或重新打开拉取请求时自动运行，方法也很简单，只需指定 pull_request 触发器，而无需任何其他配置：
on: pull_request
还可指定触发工作流的拉取请求事件。 例如，当关闭拉取请求时，以下工作流将自动运行：
on:
pull_request:
types: [closed]
重要
如果拉取请求中存在合并冲突，则工作流不会运行。 你需要解决该冲突并推送解决方法，以便工作流能够运行。
拉取请求状态检查
拉取请求工作流的结果在拉取请求的详细信息页上显示为“检查”。 检查使作者和审阅者能够快速获得有关自动活动是成功还是失败的反馈，如以下示例中所示：
默认情况下，即使检查失败，也可以合并拉取请求。 最好不要允许这样做，因此你可以配置“分支保护规则”，强制特定请求必须成功才能合并拉取请求。
更新文件
创建拉取请求后，作者通常需要更新请求。 例如：
- 审阅者可能会要求作者对代码进行更改。
- 如果自动检查失败，作者可更改代码以解决问题，然后提交并推送其更改。
通过使用 pull_request 触发器，你可以将验证工作流配置为在每次更新源分支时运行。 在拉取请求的详细信息页上显示工作流的最新运行结果。
可重用工作流
如果你查看拉取请求验证的可能检查列表，你会注意到这些与你将在常规部署工作流中运行的步骤相同。 若要避免重复，一个良好做法是使用 GitHub 的“可重用工作流”。
可以为每个将在各种工作流定义中使用的作业定义可重用工作流。 在下一练习中，你将了解如何执行此操作。
草稿拉取请求
作为一个作者，当你准备好评审、批准和合并你的更改时，你将打开一个拉取请求。 即使你尚未准备好合并更改，但如果能够在编写代码的整个过程中访问自动拉取请求验证检查，会非常有帮助。
在 GitHub 上打开拉取请求时，可以将其标记为“草稿”。 GitHub 运行所有相同的自动检查，审阅者仍然可以提供反馈。 但当拉取请求处于草稿状态时，每个人都清楚，工作尚未准备就绪，无法供全面评审或无法进行合并。
在拉取请求验证工作流创建临时环境时创建草稿拉取请求尤为常见，因为你可以在实时的工作环境中预览更改。 继续推送更改时，临时环境也会更新，以便合并最新更改。