Resources > Repository triggers not firing and default triggers not disabled in Azure DevOps yaml pipeline

Question

I have a triggers set up in our azure-pipelines.yml like so below:

1. the scriptsconn represents a connection to the default/self repo that contains the deployment pipeline yaml.

2. the serviceconn represents a microservice repo we are building and deploying using the template and publish tasks.

We have multiple microservices with similar build pipelines, so this approach is an attempt to lessen the amount of work needed to update these steps.

Right now the issue we're running into is two fold:

1. no matter what branch we specify in the scriptsconn resources -> repositories section the build triggers for every commit to every branch in the repo.

2. no matter how we configure the trigger for serviceconn we cannot get the build to trigger for any commit, PR created, or PR merged.

According to the link below this configuration should be pretty straighforward. Can someone point out what mistake we're making?

https://github.com/microsoft/azure-pipelines-yaml/blob/master/design/pipeline-triggers.md#repositories

resources:
  repositories:
    - repository: scriptsconn
      type: bitbucket
      endpoint: BitbucketAzurePipelines
      name: $(scripts.name)
      ref: $(scripts.branch)
      trigger:
        - develop
    - repository: serviceconn
      type: bitbucket
      endpoint: BitbucketAzurePipelines
      name: (service.name)
      ref: $(service.branch)
      trigger:
        - develop
      pr:
        branches:
        - develop


variables:
  - name: service.path
    value: $(Agent.BuildDirectory)/s/$(service.name)
  - name: scripts.path
    value: $(Agent.BuildDirectory)/s/$(scripts.name)
  - name: scripts.output
    value: $(scripts.path)/$(release.folder)/$(release.filename)
  - group: DeploymentScriptVariables.Dev

stages:
- stage: Build
  displayName: Build and push an image
  jobs:  
  - job: Build
    displayName: Build
    pool:
      name: 'Self Hosted 1804'
    steps:   
    - checkout: scriptsconn
    - checkout: serviceconn

Answer 1

I also struggled with this problem and after a while I found the solution. The answer of Eric Smith is no longer valid.

Now is perfectly possible to trigger a pipeline on the repo A when you push commits on the repo B.

In my example, a pipeline in the main branch (this is important) on the repo A is used for normal CI/CD, but also have a trigger for edits pushed on the repo B (main branch, but also others can be choosen).

My azure-pipeline.yml in the main branch on the repo A is:

trigger: # for usual CI/CD
  batch: true
  branches:
    include:
    - main # default branch of repo A
    - feature/*
  paths:
    include:
    - /

resources:
  repositories:
  - repository: B
    type: git
    name: "My Organization/My repo B"
    trigger:  # for edits pushed on the repo B
      - main

pool:
  vmImage: 'windows-2022'

variables:
#...
steps:
#...

... That's it!

So, why this didn't works before? The short answer is: an edit on the repo B can trigger a pipeline on the repo A only if the declaration of the trigger referencing the repo B is on the default branch of the repo A. This is clear if you read this documentation here.

When a pipeline is triggered, Azure Pipelines has to determine the version of the YAML file that should be used and a version for each repository that should be checked out. If a change to the self repository triggers a pipeline, then the commit that triggered the pipeline is used to determine the version of the YAML file. If a change to any other repository resource triggers the pipeline, then the latest version of YAML from the default branch of self repository is used

So, if you tested the pipeline of repo A on a feature branch, as normally, nothing happens.

Answer 2

The document you linked to is actually a design document. So it's possible\likely that not everything on that page is implemented. In the design document I also see this line:

However, triggers are not enabled on repository resource today. So, we will keep the current behavior and in the next version of YAML we will enable the triggers by default.

The current docs on the YAML schema seem to indicate that triggers are not supported on Repository Resources yet.

Just as an FYI you can see the current supported YAML schema at this url.

https://dev.azure.com/{organization}/_apis/distributedtask/yamlschema?api-version=5.1

I am not 100% sure on what you are after template wise. General suggestion, if you are going with the reusable content template workflow, you could trigger from an azure-pipelines.yml file in each of your microservice repos, consuming the reusable steps from your template. Hope that helps!