Azure Devops中拉取请求的构建策略能否使用上述PR中更新的yaml文件？

我们将所有管道都签入代码，但是如果我们交付了一个PR，并在这些管道中进行了更改，那么PR构建策略将与MASTER中的YAML文件一起运行，而不是我们想要签入MASTER的文件。这基本上是一个僵局

假设您要删除一个使所有PR失败的验证，因此您创建了PR，但无法合并它，从而导致生成策略失败：p

---

PS：我知道我可以删除策略，完成合并，然后将策略作为手动作业重新添加，但这不是一个好的解决方案。

使用预合并构建步骤创建一个单独的yaml管道，然后在PR策略中设置这些步骤。它将始终从创建PR的当前分支运行代码

我们这样做： （全部采用同一回购协议）

build_steps.yml-包含构建步骤的Yaml模板

azure pipelines yml-具有用于构建项目的build_steps.yml参考的主管道

pre_merge.yml-仅由PR请求运行的辅助管道，该请求具有对build_steps.yml的引用，因此在构建中没有差异，并且在发生更改时有两个地方需要更新

整个yaml定义：

#pre_merge.yml
触发器：无#管道不应在任何分支上触发。仅由策略调用。
变量：
-名称：system.buildConfiguration
值：“发布”
-名称：system.buildPlatform
值：“win10-x86”
-名称：system.debug
值：“false”
游泳池：
vmImage:“windows最新版本”
名称：$（SourceBranchName）$（日期：yyyyMMdd）$（版本：.r）
步骤：
-模板：build_steps.yml

然后在策略中按如下方式设置：

---

所有这些也适用于经典管道。您需要创建一个单独的预合并生成管道，该管道可以引用具有主生成管道中使用的步骤的任务组。在这两种情况下，您不必使用模板或任务组并手动创建步骤。但是，如果构建将来会发生变化，您有两个地方需要更新。

将此作为替代方案。然而；如果需要，您可以维护一个yaml管道，该管道可以执行预合并和部署

希望创建一个变量来检测管道是否针对“主/主”分支运行，类似于：

  IsMainBranch: $[eq(variables['Build.SourceBranch'], 'refs/heads/master')]

---

在此基础上，变量需要成为后续作业/阶段的条件。我个人不喜欢这种方法，因为它限制了管道的可移植性。此外，它还插入了另一个变量来解释；但是，我觉得提供一个替代方案是公平的。

如果下面的答案帮助您解决了这个问题，请确认答案，以便将来社区知道它是有效的。非常感谢您的债务问题答案。我们在很短的时间内就完成了！