Azure Devops 按顺序运行两个构建答案

【问题标题】：Azure Devops Running Two Builds SequentiallyAzure Devops 按顺序运行两个构建
【发布时间】：2021-02-09 06:35:42
【问题描述】：

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

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

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

【问题讨论】：

【解决方案1】：

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

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

由于构建设置

这是Pull Request trigger。

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

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

您可以查看构建的结果来判断源分支代码是否有效。

例如：

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

YAML 文件中的拉取请求签入

这可能是CI trigger。

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

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

工作流程总结：

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

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

例如：

【讨论】：

【解决方案2】：

从功能上讲，这两个构建可能并不总是相同。

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

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

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

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

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

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

【讨论】：