6.5 Pipeline Triggers, Filters & Concurrency Management

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 include pattern and an exclude pattern, the exclude rule always wins.
• Wildcard Syntax:
  • *: Matches zero or more characters within a single path segment (e.g., releases/* matches releases/v1 but NOT releases/2026/v1).
  • **: Matches zero or more characters across multiple path segments (e.g., feature/** matches feature/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

1. All Excluded: If every single file modified in a commit or push matches the paths: exclude: list, the pipeline does not run.
2. Mixed Changes: If a commit modifies three files matching paths: exclude: and at least one file matching paths: include: (or not excluded), the pipeline will trigger.
3. 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!)

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 the pr: 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:

$$\begin{array}{ccccc} \text{Minute} & \text{Hour} & \text{Day of Month} & \text{Month} & \text{Day of Week} \\ (0-59) & (0-23) & (1-31) & (1-12) & (0-6, 0=\text{Sunday}) \end{array}$$

schedules:
  - cron: '0 2 * * 1-5' # Runs at 02:00 AM UTC, Monday through Friday
    displayName: 'Nightly Weekday Regression & Security Scan'
    branches:
      include:
        - main
        - releases/v2.0
    always: true # CRITICAL FLAG

The always Keyword

• always: false (Default): The scheduled pipeline will only run if there have been new commits pushed to the specified branch since the previous scheduled execution. If no code has changed, the run is skipped.
• always: true: The pipeline executes unconditionally on schedule, even if no code changes occurred. This is mandatory for:
  • Nightly Static Application Security Testing (SAST) and software composition analysis (detecting newly published zero-day CVEs against static dependencies).
  • Long-running end-to-end synthetic performance and load tests.
  • External environment health and drift verification.

Batching CI Builds (batch: true)

When multiple developers push commits rapidly to a shared branch, queuing individual builds for every single commit causes queue explosions and long developer wait times.

trigger:
  batch: true # Batches in-flight commits
  branches:
    include:
      - main

• Mechanics of batch: true: If a pipeline run is already executing for branch main when new commits are pushed, Azure Pipelines does not start a new build immediately. Instead, it waits until the current run finishes, aggregates all commits pushed during that execution window, and executes a single combined build containing the aggregated changes.

---

5. Concurrency, Matrix Execution & Parallelism Licensing

Managing pipeline concurrency ensures efficient throughput without overloading cloud APIs, target databases, or build infrastructure.

Azure DevOps Parallel Job Licensing Models

Pipelines cannot run concurrently without allocated Parallel Jobs:

Matrix Execution Strategies (strategy: matrix)

A matrix strategy runs the same job across multiple permutations of operating systems, runtime versions, or deployment targets concurrently:

jobs:
  - job: CrossPlatformBuild
    strategy:
      matrix:
        Linux_Net8:
          imageName: 'ubuntu-latest'
          dotnetVersion: '8.0.x'
        Linux_Net9:
          imageName: 'ubuntu-latest'
          dotnetVersion: '9.0.x'
        Windows_Net8:
          imageName: 'windows-latest'
          dotnetVersion: '8.0.x'
      maxParallel: 2 # Throttles concurrency
    pool:
      vmImage: \$(imageName)
    steps:
      - task: UseDotNet@2
        inputs:
          version: \$(dotnetVersion)
      - script: dotnet test

• maxParallel: Restricts the maximum number of matrix legs that execute simultaneously. In the example above, even though 3 matrix configurations exist, only 2 execute at any given time, preserving agent pool capacity for other pipelines and avoiding database connection saturation.

Pull Request Auto-Cancellation (autoCancel: true)

In rapid pull request workflows, developers often push follow-up commits while an earlier PR build validation is still running.

pr:
  autoCancel: true # Cancels obsolete PR builds
  branches:
    include:
      - main

• When autoCancel: true is configured (supported in GitHub and Bitbucket repositories), pushing a new commit to an active PR branch immediately aborts the in-progress build and starts a new run for the latest commit. This immediately frees up build agent capacity.