Automatically Triggering ASP.NET Core Build Pipelines in Azure DevOps

1. What is a CI Trigger?

A Continuous Integration (CI) trigger automatically starts an Azure DevOps build pipeline whenever code is pushed or merged into a configured Git branch.

Instead of manually running the pipeline, Azure DevOps detects changes in the repository and starts the build process.

Main purpose:

Automatically build code after developers push changes.
Validate changes before merging through Pull Request (PR) validation.
Automatically build the latest code after a PR is merged.
Detect compilation and unit-test failures early.
Generate updated deployment artifacts.

2. How Does It Work?

Developer Changes ASP.NET Core Code
                |
                v
          git add .
                |
                v
          git commit
                |
                v
          git push
                |
                v
       Azure Repos / GitHub
                |
                v
       CI Trigger Activated
                |
                v
        Azure DevOps Pipeline
                |
                v
          dotnet restore
                |
                v
          dotnet build
                |
                v
          dotnet test
                |
                v
          dotnet publish
                |
                v
        Publish Build Artifact

Important: A local git commit alone does not trigger a normal Azure DevOps CI pipeline. The commit must be pushed to the remote repository.

3. Configure Automatic CI Trigger in YAML

Example 1: Trigger when code is pushed to `main`

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

steps:
- checkout: self

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

- script: dotnet restore MyApplication.sln
  displayName: 'Restore Packages'

- script: dotnet build MyApplication.sln --configuration Release --no-restore
  displayName: 'Build Application'

- script: dotnet test MyApplication.sln --configuration Release --no-build
  displayName: 'Run Unit Tests'

Whenever developers push changes to main, Azure DevOps automatically starts this pipeline.

Example 2: Trigger for multiple branches

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

Branch	Automatic CI
`main`	Yes
`develop`	Yes
`feature/login`	Yes
`feature/payment`	Yes
`hotfix/security`	No

This configuration runs CI for pushes to main, develop, and matching feature branches.

4. How Do You Trigger a Pipeline After a Pull Request Is Merged?

Consider the following workflow:

Developer
    |
    v
feature/login
    |
    | Push Changes
    v
Create Pull Request
    |
    v
PR Build Validation
    |
    | Build + Tests Passed
    v
Code Review and Approval
    |
    v
Merge into main
    |
    v
CI Trigger on main
    |
    v
Build + Test + Publish Artifact

There are two important pipeline executions:

Before merging: PR validation checks whether the proposed changes compile and pass tests.

After merging: The CI trigger on main builds the updated branch and generates a new artifact.

GitHub Pull Request Trigger

For a GitHub repository, PR validation can be configured using:

pr:
  branches:
    include:
      - main

This triggers PR validation for pull requests targeting main, subject to the GitHub integration and pipeline configuration.

Azure Repos Pull Request Validation

For Azure Repos Git, YAML pr: triggers are not supported. Instead, configure a Build Validation branch policy.

Steps:

Open Azure DevOps → Repos → Branches.
Select the main branch.
Open Branch policies.
Under Build Validation, select +.
Choose your ASP.NET Core build pipeline.
Set the policy to Required and automatic triggering.
Save the policy.

This ensures the PR must pass build validation before it can be completed, provided the branch policy is enforced.

5. Trigger Only When Specific Files Change

Sometimes we do not want to run the build when documentation or unrelated files change.

We can configure path filters:

trigger:
  branches:
    include:
      - main

  paths:
    include:
      - src/**
      - tests/**
      - MyApplication.sln
      - azure-pipelines.yml

The pipeline runs when relevant files change in the specified branch. Changes affecting only files outside the included paths generally do not trigger CI.

6. How Do You Disable Automatic CI?

trigger: none

This disables YAML CI push triggers.

The pipeline can still be started manually or through other configured triggers, such as schedules or pipeline resources.

7. Important Interview Questions

Q1. Does git commit automatically trigger Azure Pipelines?

No. Normally, the developer must push the commit to the remote repository. The CI trigger then detects the push.

Q2. How do you trigger a pipeline automatically after merging into main?

Configure a YAML CI trigger for main. When a PR merge updates the remote main branch, the pipeline runs automatically.

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

A CI trigger runs after code is pushed to a branch. PR validation runs before merging to validate proposed changes.

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

Using Build Validation under the target branch's policies, rather than the YAML pr: keyword.

Q5. Can we trigger pipelines for multiple branches?

Yes. We can specify multiple branches using trigger.branches.include.

Q6. Can we prevent pipeline execution for certain file changes?

Yes. We can use paths.include and paths.exclude filters.

Q7. Can we manually run a pipeline even if automatic triggers are disabled?

Yes. The pipeline can be started using the Run pipeline option in Azure DevOps, assuming the user has permission.

8. Interview-Ready Answer

In Azure DevOps, I configure CI triggers in the azure-pipelines.yml file to automatically build ASP.NET Core applications whenever code is pushed or merged into specific branches.

For example, I configure the trigger section for main and develop. When a developer pushes changes to these branches, Azure Pipelines automatically starts the build process, restores NuGet packages, compiles the solution, runs unit tests, and generates build artifacts.

For Pull Requests in Azure Repos, I configure Build Validation branch policies to ensure the code is successfully built and tested before merging.

Once the PR is merged into main, the CI trigger starts another pipeline run for the merged code.

I can also use branch and path filters to control when the pipeline executes.

Key sequence to remember:

git commit
    |
    v
git push
    |
    v
CI Trigger
    |
    v
Build + Unit Tests
    |
    v
Publish Artifact

Most important interview point: CI triggers automatically build code after a remote push or merge, while PR build validation checks proposed changes before they are merged.

Automatically Triggering ASP.NET Core Build Pipelines