Azure-devops-docs: clarification request: YAML triggers, path filters - are variables supported?

[NenoLoje]

Can we do something like:

trigger:
  paths:
    include:
    - $(ProjectName)/src/

variables:
  ProjectName: foo

Is that supported?

---

Document Details

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

• ID: 7458d5b2-1bb7-7d87-7ce6-2b0c430b0155
• Version Independent ID: edf5bbd3-a3f0-5426-e985-31290f8afd05
• Content: YAML schema - Azure Pipelines
• Content Source: docs/pipelines/yaml-schema.md
• Product: devops
• Technology: devops-cicd
• GitHub Login: @vtbassmatt
• Microsoft Alias: macoope

[vtbassmatt]

I don't recall off-hand if that works. This should, though:

trigger:
  paths:
    include:
    - ${{ variables.ProjectName }}/src/

variables:
  ProjectName: foo

(Only works because the variable is statically defined, though - if it was queue-time or computed somehow, it would not work.)

[NenoLoje]

@vtbassmatt - Yes, it's a static variable.

However, when I tried your code I get an error message:

1183: "/LibraryA/azure-pipelines.yml (Line: 13, Col: 7): A template expression is not allowed in this context"

Any idea? Any other prerequisite to make this work?

[vtbassmatt]

D'OH! We don't allow expressions in triggers for mumble mumble reasons. There's not a good workaround for the scenario - sorry 😞 You mind filing a request at https://developercommunity.visualstudio.com/spaces/21/index.html ?

[NenoLoje]

Sure, if it helps. :) Here you go: https://developercommunity.visualstudio.com/idea/717570/pipelines-support-variables-in-yaml-trigger-path-f.html

[NenoLoje]

Can we add a note to the docs to reflect that it's not possible to use variables today?

[mijacobs]

Thanks for your question. It looks like your question isn't an issue with the documentation, but an issue or question specific to your implementation or a bug in the product itself.

For help with a specific task, here are a couple of options where you might consider asking your question:

• Azure DevOps on Stack Overflow
• Azure DevOps Support Bot

If you've encountered an issue with the product itself, to make sure it gets in front of the right people, please submit your bug here.

If you have an idea for improving the product, please submit your idea here.

[NenoLoje]

@mijacobs Did the docs get fixed/clarified as the outcome of this issue?

That primary intent of this issue was to make it clear in the docs what is/isn't supported today.

[mijacobs]

HI @NenoLoje,
I'm sorry, this issue was miscategorized; I've re-categorized and re-opened it.

[ayoubeddafali]

This feature would be very helpful !!

[NenoLoje]

This feature would be very helpful !!

Great. If you want it, make sure to add your vote at: https://developercommunity.visualstudio.com/idea/717570/pipelines-support-variables-in-yaml-trigger-path-f.html

That's where your voice counts. :)

[vtbassmatt]

Fix in progress

[AlexDenton]

@vtbassmatt

I see this issue has been closed. Does that mean the fix is out?

And by chance would it also work for variables defined through the interface rather than in the yaml file?

[vtbassmatt]

The docs are fixed, reflecting the reality that variables and templates are not parsed in triggers.

[AlexDenton]

Got it. Thank you!

[Beej126]

friendly reminder for anyone else trying to achieve single consolidated yml file for multiple pipeline definitions...

we can set the triggers up at the GRAPHICAL pipeline settings (and then leave that out of the yml)

gathering all the links i found while looking:

• https://github.com/MicrosoftDocs/vsts-docs/issues/5409
• https://github.com/MicrosoftDocs/vsts-docs/issues/2691
• https://developercommunity.visualstudio.com/idea/717570/pipelines-support-variables-in-yaml-trigger-path-f.html
• https://developercommunity.visualstudio.com/content/problem/380221/yaml-build-pipeline-path-triggers-do-not-support-v.html

[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.