VSTS / TFS trigger build only on push to Git subfolder

Jun 16, 2016 | | 3 min |  #cicd #git

I’ve discovered today by chance that VSTS now supports build triggers only on subfolder in git branch. The absence of this feature before prevented us from keeping several projects in one git repository and forced to some untrivial code sharing techniques when absolutely not required. I stumbled upon this feature while hunting for a way to stop unrelated pushes from firing our builds. VSTS (now Azure DevOps) lets you add path filters to a build definition so the build only runs when files in specific subfolders change — perfect for monorepos.

Why this is useful

  • It stops noisy CI runs. Our team used to waste time and build minutes every time someone touched unrelated docs or a different project.
  • It keeps a single-repo workflow simple without forcing awkward project splits or convoluted code sharing.

What it does (in plain words)

In the build definition you add include/exclude path filters. If a push contains changes that match an include filter, the build runs; otherwise it doesn’t. You can combine multiple filters and scope them to branches.

Practical example: add APIS/* as an include filter. Now only pushes that change files under APIS/ will kick off that build — everything else is ignored.

How I set it up (classic build editor)

  1. Edit the build definition and open the “Triggers” tab.

  2. Turn on Continuous Integration and open Path filters.

  3. Add your include filter(s), for example:

    • APIS/* — trigger when files under APIS/ change
    • projects/my-app/** — trigger for any change under projects/my-app

  4. Optionally add exclude filters for generated files or folders you never want to trigger builds.

  5. If needed, also set a branch filter (e.g. master) so the build runs only when both branch and path match.

Patterns you’ll find handy

  • APIS/* — files directly under APIS/
  • APIS/** — files at any depth beneath APIS/
  • src/*.cs — C# files directly under src
  • !docs/** — exclude everything under docs

You can mix include and exclude rules. For example include APIS/** but exclude APIS/tmp/** to ignore temporary changes.

What if your TFS doesn’t have this UI?

Older TFS installs may not show path filters. I ran into that too. Two simple options:

  1. Let the build trigger and bail out fast if nothing relevant changed. I added a tiny PowerShell step at the start of our pipeline that inspects the changed files and exits with success when there’s nothing to do:
# fetch latest refs and get filenames changed in this push
git fetch --quiet origin
$changed = git diff --name-only $env:BUILD_SOURCEVERSION^..$env:BUILD_SOURCEVERSION
if (-not ($changed -match '^(APIS/|projects/my-app/)')) {
  Write-Host "No relevant changes — skipping build steps."
  exit 0
}
  1. If CI isolation is critical and you can’t tolerate the extra trigger, split the repo. Not ideal, but sometimes practical.

Quick tips from experience

  • Make a small test commit touching only excluded paths to verify your filters behave as expected.
  • Use both branch and path filters for release pipelines so builds run only for the right branch and the right subfolder.
  • Exclude docs, generated assets and other noisy paths to keep build history meaningful.

Path-based triggers fixed a real pain for us: we kept multiple projects in one repo and finally stopped wasting CI runs on unrelated changes. If your Azure DevOps shows the path filters UI, it’s a two-minute change that pays off quickly.