Azure DevOps YAML – CI and PR Triggers

1. What are CI and PR Triggers?

In Azure DevOps YAML pipelines, Triggers determine when a pipeline should execute automatically.

The two most important triggers are:

• CI Trigger (Continuous Integration): Automatically runs a pipeline when code is pushed to a configured branch.

• PR Trigger (Pull Request): Automatically runs a validation pipeline when a Pull Request is created or updated.

Both help detect build failures, compilation errors, and test failures before code reaches Production.

CI Trigger vs PR Trigger

Important: Azure Repos Git and GitHub handle PR triggers differently. We will cover this below.

2. How Does a CI Trigger Work?

A CI trigger automatically starts a pipeline when a developer pushes code to a configured branch.

Example

Suppose your repository contains two branches:

• develop – Development branch

• main – Production branch

You want the pipeline to run whenever code is pushed to either branch.

YAML configuration

trigger:
  branches:
    include:
      - main
      - develop

Execution flow

Basic CI pipeline example

trigger:
  - main
  - develop

pool:
  vmImage: 'ubuntu-latest'

steps:
  - script: dotnet restore
    displayName: 'Restore Packages'

  - script: dotnet build --no-restore
    displayName: 'Build Application'

  - script: dotnet test --no-restore
    displayName: 'Run Unit Tests'

When code is pushed to main or develop, Azure DevOps automatically executes these steps.

3. Different Types of CI Trigger Configuration

A. Trigger for a single branch

trigger:
  - main

Runs only when changes are pushed to main.

B. Trigger for multiple branches

trigger:
  branches:
    include:
      - main
      - develop
      - feature/*

Runs for pushes to:

• main

• develop

• Branches matching feature/*

C. Exclude specific branches

trigger:
  branches:
    include:
      - '*'
    exclude:
      - experimental/*

Runs for all branches except those matching experimental/*.

D. Disable CI trigger

trigger: none

Disables YAML CI push triggers.

The pipeline can still run manually or through other configured triggers.

4. What is a PR Trigger?

A Pull Request trigger validates proposed code changes before they are merged into a target branch.

Suppose you are working on:

feature/login

You want to merge your changes into:

main

Before approving the Pull Request, Azure DevOps should automatically:

1. Restore packages.

2. Build the application.

3. Execute unit tests.

4. Report whether the proposed changes pass validation.

This helps prevent defective code from entering main.

PR validation flow

5. PR Trigger in GitHub vs Azure Repos

This is a very important interview concept.

A. GitHub repository

For a GitHub repository connected to Azure Pipelines, you can configure PR triggers in YAML.

pr:
  branches:
    include:
      - main
      - develop

This runs PR validation when a Pull Request targets main or develop, subject to the pipeline's trigger settings.

B. Azure Repos Git repository

Azure Repos Git does not support YAML pr triggers.

Instead, PR validation is configured using Branch Policies → Build Validation.

How to configure PR validation in Azure Repos

1. Open Azure DevOps.

2. Navigate to Repos → Branches.

3. Locate the main branch.

4. Select the branch's More options (…) → Branch policies.

5. Under Build validation, add a build policy.

6. Select your YAML pipeline.

7. Set the policy to Required.

8. Configure automatic triggering and save.

Now, when a Pull Request targets main, Azure DevOps can automatically run the selected validation pipeline.

If validation fails, the PR cannot be completed while the required policy remains unsatisfied.

6. CI and PR Trigger – Combined YAML Example

For a GitHub repository, the following pipeline enables both CI and PR validation.

# CI Trigger
trigger:
  branches:
    include:
      - main
      - develop

# Pull Request Trigger (GitHub)
pr:
  branches:
    include:
      - main
      - develop

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

stages:
  - stage: Build
    displayName: 'Build and Test'

    jobs:
      - job: BuildJob

        steps:
          - task: UseDotNet@2
            inputs:
              packageType: 'sdk'
              version: '8.0.x'

          - script: dotnet restore
            displayName: 'Restore Packages'

          - script: dotnet build --configuration $(buildConfiguration) --no-restore
            displayName: 'Build Application'

          - script: dotnet test --configuration $(buildConfiguration) --no-build
            displayName: 'Run Unit Tests'

What happens in different scenarios?

This table assumes a GitHub repository, the YAML configuration above, and default enabled PR validation behavior. Azure Repos requires branch-policy configuration instead.

7. Path Filters in CI and PR Triggers

Sometimes you want a pipeline to run only when particular files or folders change.

For example, your repository contains:

MyApplication/
│
├── Backend/
│   └── WebAPI/
│
├── Frontend/
│   └── Angular/
│
└── azure-pipelines.yml

You want the .NET pipeline to run only when backend files change.

CI path filter

trigger:
  branches:
    include:
      - main

  paths:
    include:
      - Backend/**

This triggers CI for qualifying pushes to main that change files under Backend/.

PR path filter for GitHub

pr:
  branches:
    include:
      - main

  paths:
    include:
      - Backend/**

This validates eligible PRs targeting main when matching backend paths change.

For Azure Repos, configure path filters within the Build Validation branch policy instead.

8. Important Trigger Properties

Example: CI batching

trigger:
  batch: true
  branches:
    include:
      - main

When changes arrive while a CI run is active, Azure Pipelines can batch subsequent changes into a later run rather than starting a separate run for every push.

Example: PR auto-cancel for GitHub

pr:
  autoCancel: true
  branches:
    include:
      - main

When new commits update an open PR, Azure Pipelines can cancel an earlier PR validation run and start validation for the newer changes.

9. Advantages and Disadvantages

10. Important Interview Questions and Answers

Q1. What is the difference between CI and PR triggers?

CI triggers execute pipelines when code is pushed to configured branches. PR triggers validate proposed changes before they are merged.

Q2. What is the YAML syntax for a CI trigger?

trigger:
  - main

Q3. How do you configure a PR trigger in Azure Repos?

Use Branch Policies → Build Validation. Azure Repos Git does not support YAML pr triggers.

Q4. Can a pipeline have both CI and PR triggers?

Yes. A pipeline can run for pushes and PR validation. GitHub supports both through YAML, while Azure Repos uses YAML CI triggers and branch-policy build validation.

Q5. What is the difference between branch filters and path filters?

Branch filters determine which branches can trigger a pipeline. Path filters restrict execution based on changed files or folders.

Q6. What happens if PR validation fails?

The pipeline reports failure. If the build validation policy is required, the PR cannot be completed until the policy is satisfied.

Q7. How do you disable automatic CI execution?

trigger: none

Q8. Does a PR trigger automatically deploy the application?

Not necessarily. A PR trigger starts the configured pipeline. Deployment happens only if deployment stages are included and their conditions permit execution. Normally, PR pipelines should validate code without deploying to Production.

11. Key Points to Remember

• CI Trigger: Runs when code is pushed to configured branches.

• PR Trigger: Validates proposed code before merging.

• trigger: YAML keyword for CI.

• pr: YAML keyword for PR validation in GitHub and other supported repositories.

• Azure Repos: Uses Build Validation branch policies for PR validation.

• Branch filters: Control which branches qualify.

• Path filters: Control which file changes qualify.

• batch: true: Helps reduce redundant CI runs.

• autoCancel: true: Cancels superseded PR runs where supported.

• Required build validation: Can prevent merging when validation fails.

Interview-ready answer

CI and PR triggers automate pipeline execution in Azure DevOps. A CI trigger runs when developers push code to configured branches, while a PR trigger validates proposed changes before merging. CI triggers are configured using the trigger keyword in YAML. For GitHub repositories, PR triggers can be configured using the pr keyword. However, Azure Repos Git uses branch policies with Build Validation for PR triggers. Branch and path filters allow us to control when pipelines execute, helping maintain code quality and reduce unnecessary builds.