Azure DevOps pipeline trigger does not fire

5
votes

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)
2
azure-devopsazure-pipelines
I try to reproduce your setting. Just a quick question: Are both pipelines "Release" pipelines or do you mean by CI/CD that "CI = Build" and "CD = Release"? – Jonas
Another question: Are both pipelines created as YAML file or with the classical editor? – Jonas
@Jonas: They're both YAML pipelines. The CI/CD distinction is about the functional application and not relevant to the technical issue at hand. I edited the description. – Jan Wicher
Ok, I reproduced the setting and I face the same behavior as in your test orga - everything works fine. B gets automatically triggered by the completion of A. Just another question to clarify: You said that all preview features are the same including the Multi-stage pipelines feature. What is the actual status of this feature? Is it enabled or disabled on both organizations? – Jonas
I have only one idea what the cause of your problem could be. In your production organization please open Pipelines > At Pipeline B Click Edit from the 3-dot-menu on the right side > Click Triggers at 3-dot-menu at the top-right-corner > Ensure the Override the YAML continuous integration trigger from here option is not checked. – Jonas

2 Answers

6
votes

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
votes

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