git - Azure Devops 按顺序运行两个构建

Question

我们有 Azure Devops 设置。现在我们的项目将构建两次。

一次是在 YAML 文件中的 Pull Request Checkin 期间，另一次是由于构建设置（下图）。

这会触发两次构建，并导致我们的构建时间加倍。我们的 Devops 团队提到这是常规做法。为什么 Azure Devops 不只触发一次构建，或者两次构建更安全？

score 0 · Accepted Answer

从功能上讲，这两个版本可能并不总是相同的。

假设您有以下示例。大写字母是提交，小写字母是潜在提交。

  e e'
 /   \
|  |   D
C  |   B 
 \ |  /
   A

这表明，两个分支来自 A 提交（主分支）。每个特性分支都为每个特性分支创建了一个 PR。一个分支在 e 提交上构建，另一个分支在 e' 提交上构建。Azure devops 无法确定先合并哪个 PR。

一旦你合并了两个 PR，你最终会在 master 中得到一个以前没有构建的新提交。这在此处进行了描述

   F
   E \
 / |   D
C  |   B 
 \ |  /
   A

如果您想消除在 master 上构建的需要，您可以将构建过期时间设置为Immediately when branch name is updated

score 0 · Accepted Answer

为什么 Azure Devops 不只触发一次构建，或者两次构建更安全？

据我所知，这是 Azure Devops 的预期工作流程。

由于构建设置

这是拉取请求触发器。

此触发器发生在 Pull Request 的过程中，PR 触发器旨在在创建 PR 时运行。

这个触发器相当于一个验证步骤，文件并没有真正提交到目标分支（预合并到目标分支）。

您可以检查构建的结果以确定源分支代码是否有效。

例如：</p>

如果拉取请求触发器失败，您可以拒绝拉取请求。不影响目标分支，目标分支保持原始状态

YAML 文件中的拉取请求签入

这可能是CI 触发器。

这个触发器将在拉取请求完成时发生。

在这种情况下，目标分支已更改。目标分支的变化触发 CI 触发器。这可以再次检查代码是否有效。

工作流程总结：</p>

创建拉取请求 -> 拉取请求触发器（预合并和最触发检查）-> 完成拉取请求 -> CI 触发器（完成分支合并和第二次检查）。

顺便说一句，如果你想排除一些文件，使它们不会触发 Pull Request Trigger，你可以添加一个路径过滤器。

例如：

2 回答 2