Azure Pipelines – Triggers (CI, PR, Scheduled, and Manual)

1. What is a Trigger in Azure Pipelines?

A Trigger in Azure Pipelines is an event or condition that automatically starts a pipeline execution.

Instead of manually starting a pipeline every time, triggers allow Azure DevOps to execute builds, tests, and deployments when specific events occur.

For example:

• A developer pushes code to the main branch.

• A developer creates or updates a Pull Request.

• A scheduled time is reached.

• A user manually starts a pipeline.

• Another pipeline completes successfully.

Main purpose: Automate CI/CD workflows and ensure code changes are validated and delivered consistently.

2. Types of Azure Pipeline Triggers

3. How Do Pipeline Triggers Work?

4. Continuous Integration (CI) Trigger

A CI Trigger automatically starts a pipeline when code is pushed to a specified branch.

YAML example

trigger:
- main

pool:
  vmImage: 'windows-latest'

steps:
- script: dotnet build
  displayName: 'Build Application'

How it works:

1. Developer modifies an ASP.NET Core Web API.

2. Developer commits the changes.

3. Developer pushes the changes to main.

4. Azure Pipelines automatically starts.

5. The agent builds the application.

Important: A local git commit alone does not trigger the pipeline. The changes must be pushed to the remote repository.

Trigger multiple branches

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

This triggers CI when changes are pushed to matching branches.

Exclude branches

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

Only the included, non-excluded branches trigger CI.

Trigger only when specific files change

trigger:
  branches:
    include:
    - main

  paths:
    include:
    - src/**
    exclude:
    - docs/**

This runs the pipeline for qualifying changes under src, but not for changes affecting only docs.

5. Pull Request (PR) Trigger

A PR Trigger runs validation when a Pull Request is created or updated.

Its main purpose is to validate proposed changes before they are merged into a protected branch.

YAML example – GitHub repository

pr:
  branches:
    include:
    - main
    - develop

This YAML PR trigger is supported for GitHub and Bitbucket Cloud repositories.

Important: Azure Repos behaves differently

For Azure Repos Git, YAML pr: triggers are not supported.

Instead, configure Build Validation through Azure Repos branch policies.

Steps:

1. Open Azure Repos → Branches.

2. Select the target branch, such as main.

3. Open Branch policies.

4. Under Build validation, add the pipeline.

5. Set the policy to Required.

6. Configure the trigger and save.

Example workflow

Developer
    |
    v
feature/login Branch
    |
    v
Create Pull Request to main
    |
    v
Build Validation Pipeline
    |
    |-- Build Application
    |-- Run Unit Tests
    |
    v
Build Successful?
    |
    +-- No  → PR blocked by required policy
    |
    +-- Yes → Other required checks/reviews
                    |
                    v
                Merge to main

Key point: PR validation helps prevent code that fails required checks from being merged into protected branches.

6. Scheduled Trigger

A Scheduled Trigger runs a pipeline automatically at specified times, even when developers have not pushed new code.

Common uses include:

• Nightly builds.

• Daily automated testing.

• Scheduled security scans.

• Periodic integration tests.

YAML example

schedules:
- cron: "0 22 * * *"
  displayName: 'Nightly Build'

  branches:
    include:
    - main

  always: true

Explanation:

Azure Pipelines YAML cron schedules use UTC.

For example, 22:00 UTC corresponds to 3:30 AM IST the following day.

Without always: true, scheduled runs may be skipped when there have been no qualifying changes since the last successful scheduled run.

7. Manual Trigger

A Manual Trigger allows a developer or authorized user to start a pipeline whenever required.

YAML example

trigger: none
pr: none

pool:
  vmImage: 'windows-latest'

steps:
- script: dotnet build
  displayName: 'Build Application'

Here:

• trigger: none disables YAML CI triggers.

• pr: none disables YAML PR triggers where supported.

• The pipeline can still be started manually.

Other configured triggers, such as schedules or pipeline-completion triggers, must also be disabled if you want manual execution only.

How to run manually

1. Open Azure DevOps → Pipelines.

2. Select the pipeline.

3. Click Run pipeline.

4. Choose the branch and any required parameters.

5. Click Run.

Real-world example: A release engineer manually starts a Production deployment pipeline after receiving approval.

8. Pipeline Completion Trigger

A Pipeline Completion Trigger starts one pipeline when another pipeline completes successfully.

For example:

Build Pipeline
      |
      |-- Restore
      |-- Build
      |-- Test
      |-- Publish Artifact
      |
      v
Successful Completion
      |
      v
Deployment Pipeline
      |
      |-- Download Artifact
      |-- Deploy to SIT

YAML example

resources:
  pipelines:
  - pipeline: buildPipeline
    source: 'MyBuildPipeline'
    trigger: true

Here, MyBuildPipeline is the source pipeline name.

When the source pipeline completes successfully, the dependent pipeline can automatically start.

Pipeline completion triggers can also be configured with branch and stage filters.

9. How to Disable Automatic Triggers

Sometimes, you want the pipeline to execute only when explicitly started.

For example, you might disable automatic CI builds for a release pipeline.

trigger: none

To disable YAML PR triggers where supported:

pr: none

Remember: Azure Repos PR validation is controlled through branch policies, not the YAML pr: setting.

10. Real-world Scenario – ASP.NET Core CI/CD

Suppose your organization uses:

• feature/* branches for development.

• develop for integration.

• main for Production-ready code.

This configuration supports automated code validation while allowing controlled Production releases.

11. Important Interview Questions

Q1. What is the difference between a CI trigger and a PR trigger?

A CI trigger runs when code is pushed to a configured branch. A PR trigger validates proposed changes before merging.

Q2. Does a Git commit automatically trigger Azure Pipelines?

No. A CI trigger normally executes when changes are pushed to the remote repository.

Q3. How do you configure PR validation in Azure Repos?

Configure Build Validation under the target branch's policies.

Q4. Can Azure Pipelines run without code changes?

Yes. Scheduled triggers with always: true, manual runs, and pipeline-completion triggers can execute without new commits.

Q5. How do you disable automatic CI triggers?

Use trigger: none in the YAML pipeline.

Q6. Can one pipeline trigger another pipeline?

Yes. Use pipeline resource completion triggers.

12. Interview-ready Answer

Azure Pipelines supports different triggers to automate CI/CD execution.

A CI Trigger starts a pipeline when developers push code to a configured Git branch.

A Pull Request Trigger validates proposed changes before merging. In Azure Repos, PR validation is configured using branch policies and build validation.

A Scheduled Trigger runs pipelines at predefined times, such as nightly builds or automated tests.

A Manual Trigger allows authorized users to execute pipelines on demand.

Azure Pipelines also supports Pipeline Completion Triggers, where one pipeline starts after another pipeline completes successfully.

These triggers help automate development workflows, enforce code quality, and control application releases.

Key interview point: CI triggers validate pushed code, PR validation checks changes before merging, scheduled triggers run at defined times, and manual triggers provide on-demand execution.

Official reference: Microsoft Learn – Azure Pipelines Triggers.