Azure DevOps分支策略构建验证相关技术问题咨询

这俩问题都是Azure DevOps分支策略里构建验证的常见坑点，我结合实际踩过的经验和官方运行机制给你掰扯清楚：

首先得说，Azure DevOps分支策略的UI里列出项目内所有流水线（包括其他仓库的），其实是设计上的一个“宽泛选项”，但默认情况下选其他仓库的流水线不仅没太大实用价值，还确实达不到你想要的验证效果：

• 为啥实际无法实现？ 构建验证的核心是要针对当前PR所在仓库（也就是Bar）的代码做校验，但其他仓库（Foo）的流水线默认是绑定Foo自己的代码源的。当你把Foo的流水线设为Bar分支的构建验证时，触发PR后，这个流水线还是会拉取Foo仓库的代码，根本碰不到Bar的PR变更，自然没法验证Bar分支的代码是否合格。
• 那有没有存在的意义？ 理论上只有一种极端场景：如果Bar仓库的代码强依赖Foo仓库的构建产物，你可以手动修改Foo的流水线，让它在运行时额外拉取Bar仓库的PR代码做联合验证。但这种场景非常少见，而且操作起来很麻烦，大部分情况下直接在Bar仓库内定义流水线做验证就足够了，完全没必要跨仓库折腾。

先给你讲清楚构建验证的核心运行逻辑：当你发起PR到目标分支（比如master）时，Azure DevOps会先悄悄创建一个临时的预合并分支——说白了就是把你的源分支（feature）的最新代码，合并到目标分支（master）的最新代码上，构建验证就是在这个预合并后的代码基础上执行的，目的就是提前确保合并后的代码能正常构建，避免合并后炸锅。

回到YAML的问题：

• 如果你的构建验证策略绑定的是仓库内的YAML流水线（也就是基于azure-pipelines.yml定义的流水线），默认会运行feature分支里的azure-pipelines.yml。原因很直白：你在feature分支里可能改了流水线配置（比如调整了构建步骤、换了依赖版本），这个修改也是PR的一部分，必须验证这个修改后的流水线能不能正常构建合并后的代码——要是用master的YAML，那你对流水线的改动就没机会验证了，这显然不合理。
• 当然也有例外：如果你手动把流水线配置成强制使用某个固定分支的YAML（比如硬指定用master的），那才会运行master的版本，但这属于特殊需求，不是默认行为。
• 另外，如果是用经典流水线（不是YAML定义的），那不管分支里有没有azure-pipelines.yml，都会跑经典流水线的固定配置，和分支里的文件没关系。

内容的提问来源于stack exchange，提问作者YoavKlein