PR 和 BatchedCI 触发器的结果好坏参半答案

【问题标题】：Outcome of PR and BatchedCI triggers are mixedPR 和 BatchedCI 触发器的结果好坏参半
【发布时间】：2020-10-26 11:53:49
【问题描述】：

在我们的开发中，我们使用一个 master 分支和一个 release 分支。发布分支受到保护，只有拉取请求才能更改发布分支。我们有一个从库管道获取构建工件的应用程序。

我曾经有两个 CI 管道，一个在 master 上触发更改，一个在 PR 上触发发布。这工作正常，但这两个管道几乎相同，除了一个从主管道获取库工件，另一个从发布管道获取，以编译应用程序。

为了使其更易于维护，我想合并这些管道并使用如下触发器：

# CI triggers
trigger:
  batch: true # To reduce the number of runs to start. Will batch all commits that happen during an active run
  branches:
    include:
    - master

# PR triggers
pr:
  branches:
    include:
    - master
    - release

获取正确工件的触发器和机制工作正常。

当使用发布工件编译失败时，git 上的 PR 正确显示了这一点。但是，当 master 上的 batchedCI 触发的管道运行成功时，PR 显示运行成功（使用发布工件时不正确）。

我怎样才能使用这个单一的管道，并让 git PR 只查看由该 PR 触发的管道运行，而忽略那些由 master 上的 BatchedCI 触发的运行？

【问题讨论】：

我不确定我是否跟随你想让这个管道只为 PR 而不是为 CI 触发器运行，对吗？
不，我想为 PR 和 CI 触发器使用相同的管道。问题是，如果 PR 触发器失败，并且后续 CI 触发器成功，则 PR 被认为是成功的，因为最近一次运行成功。管道本身的行为取决于它是 PR 还是 CI 触发器，例如。它从不同的管道中获取所需的库工件。取决于此，管道可能成功或失败。
你使用 Azure Repos 还是 Github？
@KrzysztofMadej 我正在使用 Github（企业版）。

标签： azure-devops azure-pipelines

【解决方案1】：

抱歉，默认情况下无法执行此操作。

你已经分析清楚并提到了根本原因：

问题是，如果 PR 触发失败，随后的 CI 触发成功，则 PR 被认为是成功的，因为最近一次运行成功。

作为一种解决方法，您可以尝试为您的 PR 添加额外的状态检查。

分支策略是确保高质量代码的强大功能通过为所有拉取请求建立要求来创建您的仓库。外部的服务可以使用 PR Status API 将详细状态发布到您的公关。外部服务的分支策略带来了能力那些参与公关工作流程的第三方服务和制定政策要求。

有关详细信息，您可以在此处参考我们的官方文档：

如果您觉得这让事情变得更加复杂，那么简单地保留两条管道也是一种选择。

【讨论】：

听起来确实是额外的复杂层。出于兴趣，我会研究它以加深我对该主题的理解，但目前坚持两条管道，并且很可能保持这种方式。感谢您澄清默认情况下它并不那么简单！
它确实帮助我不走我正在走的路。完成:-)。