6.5 Pipeline Triggers, Filters & Concurrency Management
Key Takeaways
- Continuous Integration (CI) triggers automate pipeline execution upon code commits, leveraging branch and tag inclusion/exclusion filters to isolate release branches from development work.
- Path filters prevent resource-draining, redundant builds in monorepos by restricting triggers to modified directories or explicitly excluding documentation and markdown files.
- Pull Request (PR) triggers in YAML configure automated validation builds for external forks or GitHub repositories, but in Azure Repos, Branch Policies strictly supersede YAML PR triggers.
- Scheduled triggers utilize 5-field cron syntax with flags like always: true to enforce nightly compliance scans regardless of code changes, and batch: true to consolidate rapid commit sequences.
- Concurrency management prevents deployment collisions and resource exhaustion through parallel job licensing, matrix execution strategies, stage-level approvals, and autoCancel: true for obsolete pull request runs.
6.5 Pipeline Triggers, Filters & Concurrency Management
Enterprise CI/CD systems must intelligently manage when pipelines execute and how many jobs run concurrently. Uncontrolled pipeline triggers waste expensive compute resources, flood agent queues, generate noise for developers, and risk deployment collisions. Conversely, improperly configured filters can cause critical integration tests to be skipped.
On the AZ-400 exam, candidates are evaluated on their ability to configure Continuous Integration (CI) triggers, monorepo path filters, Pull Request (PR) validation mechanics, scheduled cron workflows, matrix parallelism, and concurrency throttling.
1. Continuous Integration (CI) Triggers & Branch Filters
A Continuous Integration (CI) trigger instructs the pipeline engine to execute automatically whenever code is pushed to the repository.
Basic Syntax and Default Behavior
In Azure Pipelines, the top-level trigger: keyword defines CI trigger behavior:
- Default Behavior: If a YAML pipeline completely omits the
trigger:section, Azure Pipelines applies an implicit default trigger equivalent to building all pushes on all branches (trigger: branches: include: [ '*' ]). - Disabling CI Triggers: To turn off automated push builds entirely (requiring manual or scheduled execution), explicitly set:
trigger: none
Branch Inclusion and Exclusion Rules
Complex branching strategies (such as GitHub Flow or release branching) require targeted trigger rules:
trigger:
branches:
include:
- main
- releases/*
- feature/*
exclude:
- feature/experimental/*
- feature/wip-*
Evaluation Mechanics and Precedence
- Order of Evaluation: Azure Pipelines evaluates inclusions first, followed by exclusions. If a branch matches both an
includepattern and anexcludepattern, theexcluderule always wins. - Wildcard Syntax:
*: Matches zero or more characters within a single path segment (e.g.,releases/*matchesreleases/v1but NOTreleases/2026/v1).**: Matches zero or more characters across multiple path segments (e.g.,feature/**matchesfeature/billing/stripe).
Tag Triggers
Pipelines can also trigger when git tags are created and pushed to the remote repository. This is common for triggering semantic release pipelines:
trigger:
tags:
include:
- 'v*'
- 'release-*'
exclude:
- '*-alpha'
- '*-beta'
2. Monorepo Path Filtering
In monorepos or multi-project repositories, multiple independent services, frontend applications, shared libraries, and documentation coexist in a single repository. Triggering an entire build and test suite when a developer merely edits a markdown README file severely wastes agent compute minutes.
Path Filter Syntax
Path filters restrict execution based on the file paths modified in a push:
trigger:
branches:
include:
- main
paths:
include:
- src/BillingService/**
- shared/Contracts/**
exclude:
- src/BillingService/docs/**
- '**/*.md'
Evaluation Rules for Paths
- All Excluded: If every single file modified in a commit or push matches the
paths: exclude:list, the pipeline does not run. - Mixed Changes: If a commit modifies three files matching
paths: exclude:and at least one file matchingpaths: include:(or not excluded), the pipeline will trigger. - Relative Paths: Path patterns are always relative to the root directory of the repository and must use forward slashes (
/), even on Windows-based agents.
3. Pull Request (PR) Triggers vs. Azure Repos Branch Policies
Pull Request triggers validate proposed code changes in an isolated branch before those changes are merged into the target branch.
[Developer Opens Pull Request]
│
┌────────────────────────┴────────────────────────┐
▼ ▼
[GitHub Repository] [Azure Repos Git]
│ │
Reads YAML `pr:` block YAML `pr:` block IGNORED!
│ │
Triggers Validation Pipeline Branch Policy Enforces Build
(e.g., `pr: branches: [main]`) (Project Settings -> Repositories
-> Branch Policies -> Build Validation)
PR Trigger Syntax in YAML
For repositories hosted in GitHub, GitHub Enterprise, or Bitbucket Cloud, PR triggers are defined directly in the pipeline YAML file:
pr:
branches:
include:
- main
- releases/*
paths:
include:
- src/**
exclude:
- docs/**
The Critical Azure Repos Exception (Top AZ-400 Exam Concept!)
[!IMPORTANT] AZ-400 Exam Rule: In Azure Repos Git, Pull Request triggers defined in the YAML file (
pr:) are completely ignored.
Why does Azure Repos ignore YAML pr: blocks?
- Security and Governance Architecture: In Azure Repos, build validation is treated as an administrative governance policy, not an author-controlled configuration. If YAML
pr:triggers were respected, a developer creating a feature branch could delete thepr:section from their YAML file, bypass automated testing, and merge defective code. - Enforcement via Branch Policies: In Azure Repos, PR validation builds must be configured under:
Project Settings → Repositories → Select Repository → Policies → Select Branch (e.g.,
main) → Build Validation. Here, administrators select the build pipeline, configure whether the build is Required or Optional, set a trigger filter, and define policy expiration rules (e.g., "Immediately when main is updated").
Security for Forked Repositories
When building pull requests originating from forked repositories (common in open-source projects):
- Pipeline Secrets: Secrets and secure files are not made available to PR builds from forks by default to prevent malicious pull requests from leaking credentials via
echo $SECRET. - Approval Gates: Administrators can configure pipelines to require team member approval before executing pipelines on PRs submitted by non-contributor forks.
4. Scheduled Triggers & Batching
Scheduled triggers execute pipelines at recurring temporal intervals, independent of code pushes.
POSIX Cron Syntax in Azure Pipelines
Scheduled triggers use standard 5-field POSIX cron syntax under the schedules: block:
A developer authors an Azure Pipelines YAML definition for a repository hosted in Azure Repos Git. The developer includes the following block in the YAML file: pr: branches: include: - main However, when team members open pull requests targeting the main branch, the validation pipeline does not execute automatically. What is the root cause of this behavior?
An enterprise maintains a large monorepo containing front-end web applications, back-end microservices, and documentation. Developers push frequent commits that only modify markdown files in the docs/ directory, causing unnecessary build runs that exhaust the monthly pipeline parallel job minutes. Additionally, developers frequently push rapid bursts of commits to feature branches. How should the pipeline trigger be configured to eliminate redundant runs and batch rapid commits?
In an active engineering repository, developers frequently push additional commits to their open pull request feature branches while earlier pull request validation builds are still running. This behavior saturates the build queue and forces developers to wait for outdated commits to finish testing. Which configuration prevents this queue saturation by terminating superseded pull request runs?