Question

我在Azure Devops中有两个管道：

管道A触发向母版的提交并产生一组工件

管道B成功完成管道A后触发并消耗其工件

这一切仅在正常提交到master的情况下都能正常工作，但是，如果我创建一个分支验证策略来强制将请求拉入master以成功运行管道A，则管道A的PR预合并运行永远不会触发管道B（希望它也可以用于PR，但是它的成功只是PR的可选。）

如果我直接添加管道B作为第二个分支验证（作为可选验证），则它与管道A同时运行，但是管道B不会消耗正确的工件，因为它不是由它应该消耗的运行触发的从，而是取而代之的是从期望从其下载的管道资源中获取最新的工件（这导致竞争条件，因为与管道A同时运行时，管道B总是会首先完成，因此会下载N-1工件）。

我期望的工作是：

在管道B中：

resources:
  pipelines:
  - pipeline: pipelineA
    source: PipelineA
    trigger:
        branches:
          include : 
            - '*'

然后在分支策略中为管道A添加分支验证，并为管道B添加状态检查，其状态为“ VSTS-RM / PipelineA”。但是它永远不会正确触发整个过程。

基本上我想做的是https://www.linkedin.com/pulse/end-to-end-pull-request-azure-devops-olivier-l%C3%A9ger，其中管道B只是另一个yml构建管道，而不是发布管道。

当前是否无法利用两个构建管道来做到这一点？

Answer 1

运行顺序生成管道作为Azure Devops中拉取请求分支策略的一部分

如果您想添加Pipeline A和Pipeline B作为分支验证，并且流水线B消耗了Pipeline A中的工件，那么Azure开发人员似乎还不支持这种方法。

原因：

仅将Pipeline B用作分支验证时，它将在发出PR请求后立即开始。如果未将Pipeline B用作分支验证，则就像完成Pipeline A一样，分支验证将不包括Pipeline B，在完成Pipeline A之后，PR将继续并且不会等待并验证Pipeline B。

解决方法：

我们可以将Pipeline B作为一项工作添加到Pipeline A中：

stages:
- stage: PipelineA
  jobs:
  - job: PipelineA
    displayName: PipelineA
    pool:
     name: xxx
    steps:
      ...

- stage: PipelineB
  jobs:
  - job: PipelineB
    displayName: PipelineB
    pool:
     name: xxx
    steps:
      - download: current
        artifact: XX

在这种情况下，我们只需要添加管道A作为分支验证即可。

请检查文档Stage和Publish and download artifacts以获得更多详细信息。

希望这会有所帮助。

在Azure Devops中作为“拉取请求分支策略”的一部分运行顺序生成管道

1 个答案: