Azure DevOps管道触发器未触发

huangapple go评论60阅读模式
英文:

Azure DevOps pipeline trigger does not fire

问题

问题

Azure DevOps有一个功能(在此处有文档),可以在另一个流水线完成时触发流水线。这在测试组织中可以正常工作,但在我们的主要组织中无法正常工作。可能是组织、项目、存储库甚至分支层面的问题,但我目前被卡住了,任何帮助都将不胜感激!

流水线

当流水线Pipeline A完成时,流水线Pipeline B应自动运行。

文件pipeline-a.yaml用于Pipeline A

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: echo Hello, world!
  displayName: 'Do something'

文件pipeline-b.yaml用于Pipeline B

trigger: none

pool:
  vmImage: 'ubuntu-latest'

resources: 
  pipelines:
  - pipeline: pipeline-a
    source: 'Pipeline A'
    branch: master
    trigger: 
      branches:
      - master

steps:
- script: echo Hello, world!
  displayName: 'Do something'

组织

在我的测试组织中,上述流水线可以正常运行。这意味着Pipeline A在提交时运行,完成后,Pipeline B会自动运行。

然而,在我们的生产组织中,Pipeline B不会自动运行。

发现

  • 在两个组织中,当手动启动时,两个流水线都可以正常运行。
  • 所有预览功能在两个组织的组织和个人级别都是相同的,包括多阶段流水线功能。
  • 生产组织在主分支上有分支策略,而测试组织没有策略。我没有看到与流水线触发器有关的连接,也没有进行调查。
  • 安装扩展以使它们在测试和生产中相等没有任何区别。
  • 测试组织似乎处于慢环中,仍然处于Sprint 161。编辑:在将组织升级到Sprint 162后,问题仍然存在。
  • 当我使用经典编辑器手动创建一个“构建完成触发器”时,它可以正常工作。但这会覆盖YAML流水线触发器,而我不想这样做(我想生成流水线及其触发器)。
英文:

Problem

Azure DevOps has a feature (documented here) to trigger a pipeline on completion from another pipeline.
This works fine in a test organization, but it won't work in our main organization.
There could be something on the organization, project, repository or even branching level, but I'm currently stuck and any help would be appreciated!

Pipelines

Pipeline Pipeline B should run automatically when pipeline Pipeline A completes.

File pipeline-a.yaml for Pipeline A:

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: echo Hello, world!
  displayName: 'Do something'

File pipeline-b.yaml for Pipeline B:

trigger: none

pool:
  vmImage: 'ubuntu-latest'

resources: 
  pipelines:
  - pipeline: pipeline-a
    source: 'Pipeline A'
    branch: master
    trigger: 
      branches:
      - master

steps:
- script: echo Hello, world!
  displayName: 'Do something'

Organizations

In my test organization the above pipelines run like a charm. This means that Pipeline A runs on a commit, and after completion, Pipeline B runs automatically.

Yet in our production organization, Pipeline B does not run automatically.

Discovery

  • Both pipelines run fine when started manually, in both organizations
  • All Preview features are equal on organization and personal level for both organizations, including the Multi-stage pipelines feature.
  • The production organization has branch policies on master, while the test organization does not have policies. I don't see a connection with pipeline triggers and did not investigate this.
  • Installing extensions to have them equal on test and production does not make a difference.
  • The test organization seems to be in the slow ring and was still on Sprint 161. EDIT: The issue persists after the organization was updated to Sprint 162.
  • It works when I use the classic editor and manually create a build completion trigger. But this overrides the YAML pipeline trigger and I don't want to do this (I want to generate the pipeline and it's triggers)

答案1

得分: 8

删除并重新添加管道解决了问题。因此,保留YAML文件,但删除管道,然后重新添加。

Azure DevOps后端似乎在某些时候缺少管道之间的关系。

英文:

Deleting and re-adding the pipeline did the trick. So keep the YAML file but delete the pipeline and add it again.

The Azure DevOps backend seems to miss a relationship between pipelines now and then.

答案2

得分: 8

我们今天排除了一个类似的问题。Pipeline-A 被定义为一个资源,用于被 Pipeline-B 消耗。

消耗的流水线从未被触发。删除并重新创建流水线对我们没有起作用。这个工作流/流水线是全新的,位于一个特性分支上。这最终变得很重要。

最终的修复方法是将该特性分支定义为 Pipeline-B 中的“手动和定时构建的默认分支”,你可以在 Pipeline -> 编辑 -> 触发器 -> yaml -> 获取源 中找到这个设置。预计随着我们将这段代码推广到主分支,我们将需要更新这个设置。

因此,似乎手动和定时构建的默认分支更好地命名为

手动和定时构建以及流水线完成触发的默认分支

英文:

We troubleshot a similar problem today. With Pipeline-A defined as a resource that is meant to be consumed by Pipeline-B.

The consuming pipeline was never being triggered. Deleting and recreating the pipeline did not work for us. This work\pipeline was net new and on a feature branch. That ended up being important.

The ultimate fix was defining that feature branch as the Default branch for manual and scheduled builds in Pipeline-B. You can find that setting tucked away in Pipeline -> Edit -> triggers -> yaml-> Get Sources. Expect that as we promote this code to the main branch we will need to update the setting.

So it seems like the Default branch for manual and scheduled builds would be better named

Default branch for manual and scheduled builds and Pipeline Completion Triggers

答案3

得分: 0

在我的情况下,源管道完成时出现错误,只需使用一个非常简单且没有错误的管道进行测试,代码就可以正常工作。

英文:

In my case it was as simple as the source pipeline completing with an error. Testing with a very simple non erroring pipeline and the code worked fine.

huangapple
  • 本文由 发表于 2020年1月7日 00:13:44
  • 转载请务必保留本文链接:https://go.coder-hub.com/59615401.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定