Azure-devops-docs: Are build variables supported in trigger paths?

[simonness]

I have a monorepo where I'd like to share a generic pipeline yaml file amongst several projects.

Builds do not seem to automatically trigger correctly if I use the following yaml:

trigger:
  batch: true
  branches:
    include:
    - '*'
  paths:
    include:
    - src/$(projectName)/*

Where projectName is a variable manually defined on the pipeline after its creation. If I replace $(projectName) for the actual folder name in the yaml automatic triggers work as expected. Are build variables supported in trigger paths?

I'd also like to +1 #2967 with a view to supporting monorepos, to prevent lots of CI builds triggering on new branch creation.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: f5673ec1-c7d1-e0ac-043a-8fc3d5b226a9
• Version Independent ID: b4872831-51c0-6cf8-1c56-de20beb38a80
• Content: Build pipeline triggers - Azure Pipelines & TFS
• Content Source: docs/pipelines/build/triggers.md
• Product: devops
• GitHub Login: @andyjlewis
• Microsoft Alias: alewis

[seangwright]

I'm running into this issue.

My .yml looks as follows

trigger:            
  batch: true       
  branches:         
    include:        
    - master        
  paths:
    include:
    - $(build.custom.projectName)/*

pool:
  name: Hosted Windows 2019 with VS2019

steps:
- template: build-pipeline-release-steps.yml
  parameters:
    projectName: $(build.custom.projectName)

Where my steps are all defined in build-pipeline-release-steps.yml and build.custom.projectName is a variable defined for the pipeline in the Pipelines UI.

This allows me to re-use the same .yml for every project in the repo.

Manually queuing a build works fine but a merge of a branch into master does not kick off a build.

In other .yml files where the path trigger does not include a variable, my build starts when the branch is merged into master.

[StephenHodgson]

I wasn't able to get build variables to work in path filters using the Designer workflow. Curious to know if it's supported for YAML

[seangwright]

It would be awesome if this was supported. Currently I have a .yml file for every project that I want to re-use a build pipeline for so I can create different artifacts based on different triggers.

In a repository that produces 5 artifacts I need 5 separate .yml files.

If trigger path variables were supported I would only need 1 file.

[gorillapower]

Yes we are also needing this feature, we have multiple branches and want to trigger builds dynamically.

[derwent-m]

would love to see this feature too. According to this post, it is "by design" that variables are not considered in trigger, however there is nothing in this documentation about it. If it's not supported, it should at least be documented https://developercommunity.visualstudio.com/content/problem/380221/yaml-build-pipeline-path-triggers-do-not-support-v.html

[jfboismenu]

Have you tried using ${{ variables.build.projectName }}, which gets evaluated before the file is parsed?

[seangwright]

@jfboismenu I haven't - but I'll give it a try and report back here.

Thanks!

[esamudio24]

I had tested the variable pattern ${{ variables.build.Myvariable }} it didn't work.

[mijacobs]

Thanks for your question. It looks like you're working through an issue with your scenario or implementation, rather than an issue with the documentation. Here are a couple of options where you might consider asking your question:

• Azure DevOps on Stack Overflow
• Azure DevOps Support Bot

[Haddox19]

Our branching strategy uses a new branch (Fork for Git guys) for every iteration and every release. We have dozens of builds, for each microservice and web portal. It is best for us to use a single release variable where we can change the path to the current iteration or release branch in one place instead of in each of the dozens of builds.

[reubster]

I've spent two days trying to figure this out. I also think this is a gap in the documentation. Nowhere does it mention that using variables is not supported. The fact that the trigger block is listed in the summary schema after the variables block definitely suggests otherwise.