我目前正在将代码从Gitlab迁移到Azure DevOps和Azure Pipelines。在Gitlab中，我有两个类似的回购设置：
- repo 1中的管道A运行build&UT。它触发：
- 回购2中的管道B运行解决方案测试。如果通过：
- 管道A发布工件
您可以在Gitlab中使用触发器作业中的依赖策略来实现这一点。这意味着，如果管道B失败，管道A也会失败，因此管道A中的发布阶段将被跳过。
我认为Azure Pipelines本机不支持此设置，例如使用管道完成触发器，这是对的吗？我不认为你可以让一个管道中途暂停并等待另一个，或者让上游管道的通过/失败状态与下游管道的状态镜像。
如果是这样的话，你认为什么是一个好的解决方案？是否可以在下游管道上进行PR构建验证，因此，如果管道A通过了回购1的分支X，但管道B失败了，Azure不会允许我合并分支X？
如果不支持的话，我有几个解决办法：
- 在管道a中编写一个脚本，启动管道B，睡眠并定期轮询API以检查管道B是否具有通过/失败
- 在管道A期间签出repo 2的代码，并在那里运行解决方案测试
它们中的任何一个听起来合理吗？
是否可以使Azure管道处于通过/失败状态取决于下游管道的通过/失败状态？
目前没有这种开箱即用的方式来实现这一点。
就我个人而言，你的想法是正确的。我以前也遇到过类似的请求，但这是关于发布的，但它们的实现概念是一样的。
主要思想是：
- 向管道a添加一个powershell任务，以调用REST API对管道B、2进行排队。对B管道施工成果进行周期性监测
- 在得到管道B的结果后，根据管道B的效果调用log命令
- 设置管道A的施工结果
您可以查看我以前的线程以了解更多详细信息：
是否可以运行"；最后阶段"；在Azure Pipelines中，而不知道总共有多少个阶段？
日志命令设置构建结果：
##vso[task.complete result=Failed;]DONE