Azure DevOps流水线意外触发构建

Question

更新日期：2020年2月26日

在我们的项目中，我有一个名为"MyPipeline"的流程管道，其中恢复了NuGet包，构建了解决方案并运行了测试。

在master分支上，我设置了一条策略，用于添加代码审查者，并且它还有一个"构建验证"步骤，执行"MyPipeline"。 一切都很好。

然而，我从Master创建了另一个名为NewBranch的分支，并将其同步（推送）到Azure。 在Visual Studio中进行了一些小更改后，我进行了从主分支合并，提交并同步到Azure。

当我将更改推送到Azure的NewBranch时，看到"MyPipeline"被触发，让我感到有点惊讶。 我没有在"NewBranch"上设置分支策略。 YAML文件中的触发器是：

trigger:
- master

这是什么情况？如果这种情况继续下去，我很快就会用完我的免费代理分钟数...

更新2020年2月26日：

根据下面的评论：

主分支上的提交历史记录如下：

1.星期二晚上9:10 2.星期二晚上7:47 3.星期一下午2:46

管道执行的历史记录如下：

1.星期三早上9:14 “PR自动化”

因此，在主分支上没有新的提交。但是，我知道是什么原因引起了这个问题。只是我不确定时间是否准确...

因此，我们有两个分支，主分支和NewBranch。

主分支需要两个代码审查员批准，并且它需要构建成功。由于此政策，开发人员无法直接合并到主分支-他们必须生成拉取请求。

因此，开发人员A创建了一个拉取请求，将NewBranch合并到Master。然后进行相当漫长的代码审查过程，可能需要多次添加到“NewBranch”拉取请求才能被认为是可接受的。

似乎每次将这些新提交同步到拉取请求时，都会触发一个构建。这是一件好事吗？也许是，也许不是。如果构建只会触发一次，则应在审核完所有拉取请求中的代码之后进行编译，而不是在事先触发。为什么要在这么早的阶段触发构建;在准备合并之前，主分支可能会被多个其他拉取请求更新。然而，如果有无限的资源，那么我想尽可能经常进行构建没有害处，但是a）这可能会延迟其他构建（对其他开发人员构成障碍），b）这将使用免费代理时间的限制。

- DrGriff

---

你尝试重现了吗？你检查了主历史记录吗？ - Yehor Androsov

无法在我的端上重现。但是，这很奇怪。您从构建历史记录中看到了什么？它是否表明这是来自主分支的个人CI？此外，同意上面评论中提到的内容，您的主分支历史记录如何？ - Mengdi Liang

@MerlinLiang-MSFT - 我在原始帖子中添加了一些详细信息。我想我知道为什么会发生这种情况，只是不确定是否完全同意。很高兴听听您的看法。谢谢。 - DrGriff

Answer 1

“你在问题中分享的详细信息对我理解你整个工作流程非常有帮助。尽管你表达得不是很清楚，但是，是的，你猜测的是正确的。你所面临的操作是预期的并经过设计。根本原因是你正在使用分支策略和构建验证也包含在此策略中。简而言之，你正在使用拉取请求触发器。”

---

解释：

让我们注意它的定义：

拉取请求（PR）触发器会在使用指定目标分支之一打开拉取请求时或向此类拉取请求推送更改时运行构建。

根据您添加的内容，您的开发人员正在向打开的拉取请求中推送更改（新提交）。由于以上定义，这属于PR触发器的工作范围。这就是为什么每次将新更改推送到NewBranch分支时都会触发构建的原因。

---

工作解决方案：

我同意@devpro答案的逻辑。但是它的脚本对于您的情况不可用。因为YAML中的pr只适用于GitHub和Bitbucket Cloud repos。

在这里，您正在使用VSTS repo，并为其配置了策略。因此，您只能通过分支策略配置来避免这种麻烦。

在您的构建验证面板中，您正在设置自动构建策略，对吗？

请将 Automatic 更改为 Manual，并保持 Policy requirement 的值为 Required。

现在，相应的构建流水线不会在推送新提交时自动运行，只能在有人手动运行它时进行构建。

---

针对您注意到的延迟时间，让您感到不确定，我猜测这可能是由于冲突引起的。

例如，合并从NewBranch到Master的拉取请求P1正在打开。我在NewBranch中提交了一个新的更改C1。但是，它引起了冲突。此时，构建将不会运行，因为更改实际上没有被推送到PR中。

请注意：提交是针对NewBranch的。但是，由于PR检测到存在冲突，因此尚未接受更改。您必须告诉PR要保留哪些更改。只有推送到PR的更改才能与PR触发器一起使用。

只有解决了冲突，更改（也可以说是提交）才能真正被接受并推送到PR中。然后触发构建运行。

这就是您注意到的延迟时间。

- Mengdi Liang

Answer 2

我今天看到相同的行为。

你能否尝试像这样重新编写你的管道中的触发器部分：

trigger:
  branches:
    include:
    - master

这有帮助吗？我自己还无法验证，因为我已经做出了更改，但拉取请求尚未获得批准 :)

我还有另一个存储库，在那里我没有看到那种行为，但是在那里，我的管道触发器看起来像这样：

trigger:
  - master

（注意-主之前的2个空格）

- Frederik Gheysels

Answer 3

我认为你需要在管道定义中添加pr: none以禁用自动运行。

如果未设置pr，则默认情况下会在每个PR上运行。

这将得到类似于以下内容：

trigger:
  batch: true
  branches:
    include:
    - master
  paths:
    exclude:
    - README.md

pr: none

- devpro

---

我认为这不是问题的根源，因为Azure DevOps不支持pr触发器：https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#pr-triggers - Frederik Gheysels