Introduction

Triggering an Azure DevOps pipeline only when certain folders change is a common monorepo optimization. Instead of rebuilding everything for every commit, you can use path filters so a pipeline runs only when relevant subdirectories were modified.

The important detail is that these filters belong in the pipeline trigger configuration itself. If the trigger does not match, the pipeline does not start at all.

Use YAML path filters on the trigger

In a YAML pipeline, configure branch filters and path filters together:

1trigger:
2  branches:
3    include:
4      - main
5  paths:
6    include:
7      - src/ServiceA/*
8      - src/Shared/*
9    exclude:
10      - src/ServiceA/docs/*
11
12pr:
13  branches:
14    include:
15      - main
16  paths:
17    include:
18      - src/ServiceA/*
19      - src/Shared/*

This means:

• pushes to main can trigger the pipeline
• only changes under src/ServiceA or src/Shared matter
• documentation changes under src/ServiceA/docs do not trigger the build
• pull requests targeting main follow the same folder logic

That is the standard pattern for folder-based triggering.

Create separate pipelines for separate folders

In a monorepo, the cleanest design is often one pipeline per service or deployable unit. Each pipeline watches only the directories that affect that service.

For example:

• 'service-a-pipeline.yml watches src/ServiceA/*'
• 'service-b-pipeline.yml watches src/ServiceB/*'
• 'infra-pipeline.yml watches infra/*'

This keeps pipelines focused and prevents one service from triggering unrelated builds.

Include shared folders deliberately

One common oversight is forgetting shared code. If ServiceA depends on code in src/Shared, then the Service A pipeline should watch both folders.

1trigger:
2  paths:
3    include:
4      - src/ServiceA/*
5      - src/Shared/*

Without that shared path, a change in common code may fail to trigger the pipeline that actually depends on it.

Configure pull request triggers too

Teams often configure push triggers carefully and then forget pull request triggers. If PR validation should also be folder-aware, define pr.paths explicitly.

1pr:
2  branches:
3    include:
4      - main
5  paths:
6    include:
7      - src/ServiceB/*

That keeps PR validation aligned with the same subfolder boundaries as your continuous integration builds.

Keep repository structure predictable

Path-based triggers work best when the repository layout is stable and easy to understand. Folder triggers become fragile if directories are renamed often or if ownership boundaries are unclear.

A clean layout such as this is much easier to maintain:

• 'src/ServiceA/'
• 'src/ServiceB/'
• 'src/Shared/'
• 'infra/'

The clearer the folder ownership model, the safer your path triggers become.

This also makes it easier for new team members to understand why a specific pipeline ran or did not run after a commit touching a particular directory.

Common Pitfalls

The most common mistake is putting folder checks inside pipeline steps instead of inside the trigger. That still starts the pipeline on every change and only skips work after startup.

Another issue is forgetting shared directories, which causes dependent services to miss builds when common code changes.

Teams also sometimes configure trigger but forget pr, which leads to precise push builds but overly broad pull request validation.

Finally, be careful with include and exclude patterns. An exclude rule that is too broad can silently prevent builds you expected to run.

Summary

• Use trigger.paths and pr.paths in Azure DevOps YAML to react only to changes in relevant folders.
• In monorepos, separate pipelines per service are often the cleanest approach.
• Include shared directories when multiple services depend on them.
• Configure PR path filters as well as push path filters.
• Keep folder ownership simple so the trigger rules stay trustworthy.