Azure Devops Pipeline trigger ignore paths when a tag is triggered

I have two build pipelines which build my client and API, but when I create a new git tag, both builds are triggered, even though the tag may only related to changes based on my client code.

front-end-build-ci.yml

trigger:
  branches:
    include:
      - master
  tags:
    include:
      - refs/tags/*_prodrelease*
  paths:
    include:
      - Clients/*
    exclude:
      - Api/*

api-build-ci-yml

trigger:
  branches:
    include:
      - master
  tags:
    include:
      - refs/tags/*_prodrelease*
  paths:
    include:
      - Api/*
    exclude:
      - Clients/*

Regular commits work as expected (i.e. client code triggers client build), and I have tried multiple variations of excluding paths to no avail.

Should tag filtering be ignoring paths, or should it work in the same way as branches?

A workaround would be to have more descriptive tags (i.e 20200326_prodrelease_api), but I'm trying to avoid needing two tags if both the api and client are ready for production.

When I create a new git tag, both builds are triggered, even though the tag may only related to changes based on my client code.

Should tag filtering be ignoring paths, or should it work in the same way as branches?

Sorry but I'm afraid what you encountered is the expected behavior of CI triggers. And yes, your guess is right that tag filtering is ignoring paths when tags is used in combination with branch filters that include file paths.

Please check the Note tip in official document:

If you specify tags in combination with branch filters that include file paths, the trigger will fire if the branch filter is satisfied and either the tag or the path filter is satisfied.

Cause of the issue:

That's why in your scenario both builds are triggered. Since you now use tags in combination with branch filters and file paths filters, both branch filter ok + tag ok and branch filter ok + path ok can trigger the build.

Behavior:

When not creating the tag, branch filter ok + path ok will work like client code triggers client build and api code triggers api build. And when creating the specific tag, cause branch filter ok + tag ok is always satisfied, it will trigger both two builds.

Just as you mentioned above, using more descriptive tags as a workaround is not a bad choice in this situation. In addition, if you do want the feature like making the three filters work at the same time, feel free to share your feedback by suggesting a feature in our User Voice Forum. Share the link here and members interested in that would vote for you.