Refer to the exhibit. A build pipeline uses this trigger configuration. A developer pushes a commit to the 'main' branch that modifies files in '/src/app/' and '/src/tests/'. How many builds will be triggered?
Exhibit
{
"triggers": [
{
"branchFilters": ["main", "develop"],
"paths": {
"include": ["/src/*"],
"exclude": ["/src/tests/*"]
},
"batchChanges": true,
"maxConcurrentBuildsPerBranch": 1,
"triggerType": "continuousIntegration"
}
]
}Trap 1: 0 builds, because the excluded path takes precedence.
The excluded path does not blindly outrank included paths; Azure Pipelines evaluates the set of changed files against the include/exclude filters as a whole. A build is triggered whenever any changed file matches an include, even if other files match an exclusion. Since the change set contains an included path, the excluded path cannot suppress the build, so zero builds is impossible.
Trap 2: 3 builds, because maxConcurrentBuildsPerBranch is 1 but…
maxConcurrentBuildsPerBranch controls the maximum number of builds that can run simultaneously for a branch, not the number of builds triggered by a single push. Setting it to 1 means one build runs at a time; any additional triggered builds would wait in the queue, but batchChanges already consolidates all changes from the same push into a single build. Therefore, the concurrency limit does not multiply the trigger count to three.
Trap 3: 2 builds, one for each modified folder.
The trigger is branch-conditioned and path-filtered, but it does not iterate over folders and create one build per folder; a single push is processed as one event. When batchChanges is enabled, every change in that push is folded into one build, so having changes in two modified folders does not yield two builds. This option confuses path filtering (which merely includes or excludes files) with build-per-path semantics.
- A
1 build, because batchChanges is true.
With batchChanges set to true, all commits and file changes from a single push are coalesced into one build invocation; you don't get a separate build per modified file or folder. Because at least one changed path matches an include pattern, the pipeline queues exactly one batched build for that change set.
- B
0 builds, because the excluded path takes precedence.
Why it fails: The excluded path does not blindly outrank included paths; Azure Pipelines evaluates the set of changed files against the include/exclude filters as a whole. A build is triggered whenever any changed file matches an include, even if other files match an exclusion. Since the change set contains an included path, the excluded path cannot suppress the build, so zero builds is impossible.
- C
3 builds, because maxConcurrentBuildsPerBranch is 1 but batchChanges overrides.
Why it fails: maxConcurrentBuildsPerBranch controls the maximum number of builds that can run simultaneously for a branch, not the number of builds triggered by a single push. Setting it to 1 means one build runs at a time; any additional triggered builds would wait in the queue, but batchChanges already consolidates all changes from the same push into a single build. Therefore, the concurrency limit does not multiply the trigger count to three.
- D
2 builds, one for each modified folder.
Why it fails: The trigger is branch-conditioned and path-filtered, but it does not iterate over folders and create one build per folder; a single push is processed as one event. When batchChanges is enabled, every change in that push is folded into one build, so having changes in two modified folders does not yield two builds. This option confuses path filtering (which merely includes or excludes files) with build-per-path semantics.