Azure DevOps 管道构建意外触发

Question

已更新2020 年 2 月 26 日

在我们的项目中，我有一个管道 "MyPipeline" 可以恢复 NuGet 包、构建解决方案并运行测试。

在 master 分支上，我有一个执行诸如添加代码审阅者之类的策略，并且它有一个执行 "MyPipeline" 的 "build validation" 步骤。一切都很好。

但是，我从 Master 创建了另一个名为 NewBranch 的分支，并将其同步（推送）到 Azure。在 Visual Studio 中做了一些小改动后，我从 master 中进行了 merge，提交并同步到 Azure。

然后看到 "MyPipeline" 执行时我有点惊讶。它似乎是在我将对 NewBranch 的更改推送到 Azure 时触发的。我在 "NewBranch" 上没有分支政策。 YAML 文件中的触发器是：

trigger: - master

是什么引起的？如果这种情况继续下去，我很快就会耗尽我的自由球员时间...

2020 年 2 月 26 日更新

根据以下评论：

master 分支上的提交历史是：

星期二 9:10 下午

星期二 7:47 下午

周一2:46下午

管道执行历史显示：

周三 9:14 上午 "PR Automated"

因此，没有任何新内容提交到 Master 分支。但是，我想我知道是什么原因造成的。只是我不相信时机....

所以，我们有两个分支，master 和 NewBranch。

Master 有一项政策要求两个代码审阅者批准，并且它要求构建成功。由于这项政策，开发人员因此不能直接合并到 master - 他们必须生成一个 Pull Request。

因此，开发人员 A 创建了一个合并请求以将 NewBranch 合并到 Master。然后是相当冗长的代码审查过程，在 "NewBranch" 的合并请求被认为可以接受之前可能需要多次额外提交。

似乎正在发生的事情是，每次将这些新提交之一同步到合并请求时，都会触发构建。这是一件好事吗？也许，也许不是。如果构建只触发一次，那么编译应该在 Pull Request 中的所有代码都被批准时进行，而不是事先。为什么要在这么早的阶段触发构建； master 分支可能会在准备合并之前被多个其他 Pull Requests 更新。但是，由于资源是无限的，所以我想尽可能多地构建没有坏处，但是a) 这可能会延迟其他构建（对其他开发人员构成障碍）和 b) 这会耗尽代理时间的免费限制。

Answer 1

我今天看到了同样的行为。

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

trigger:
  branches:
    include:
    - master

有帮助吗？我还不能自己验证，因为我已经完成了那个更改，但是 PullRequest 还没有被批准 :)

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

trigger:
  - master

（注意前面的两个空格 - master）

Answer 2

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

如果未设置 pr，我认为每个 PR 的默认设置都是运行。

那会给出这样的东西：

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

pr: none

Answer 3

你分享的详细信息对我了解你的整个工作流程有很大帮助。

虽然你没有表达的太清楚，但是，是的，你猜的是对的。您面临的操作是预期的并且是设计好的。根本原因是您正在使用 branch policy 并且 Build validation 也包含在此政策中。

简而言之，您正在使用 Pull request trigger。

解释:

我们注意一下它的定义：

Pull request (PR) triggers cause a build to run whenever a pull request is opened with one of the specified target branches, or when changes are pushed to such a pull request.

根据您添加的内容，您的开发人员正在推送更改（新提交）到开放拉取请求（注意：重点是Pull request is still be opening.) 由于以上定义，这属于PR trigger的工作范围。这就是为什么构建会触发每个推入 NewBranch b运行ch 的新更改。

解决方法：

我同意@devpro 回答的逻辑。但它的脚本不适用于您的场景。因为 YAML 中的 pr 仅适用于 GitHub 和 Bitbucket Cloud 存储库。

这里您使用的是 VSTS 存储库，并为其配置了策略。所以，只能通过b运行ch policy配置来避免这种烧毁的麻烦。

在您的构建验证面板中，您正在使用 Automatic 设置构建策略，对吗？

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

现在，一旦新提交被推送，相应的构建管道将不会运行自动，它只能在某人运行它手动时构建。

对于你注意到的延迟时间让你不确定，我猜是因为冲突。

例如，从 NewBranch 合并到 Master 的合并请求 P1 正在打开。我将新更改 C1 提交到 NewBranch。但是，它会导致冲突。此时，构建不会运行因为更改并没有真正推送到 PR 中。

注意： 提交符合 NewBranch。但是更改还没有被 PR 接受，因为 PR 检测到这里有冲突，你必须告诉 PR 你想保留哪些更改。只有推送到 PR 的更改才能与 PR 触发器一起使用。

只有解决了冲突，修改，也许我可以说是commit，才能真正被接受并推入PR。然后触发构建运行.

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

Azure DevOps 管道构建意外触发

Azure DevOps Pipeline build triggering unexpectedly

azure

azure-devops

azure-pipelines-build-task

azure-pipelines