Pipeline Triggers - Azure DevOps Tutorials

Understanding Pipeline Triggers

Pipeline triggers automate the execution of your build or release pipelines. They allow your pipelines to start automatically when certain events occur, such as code commits, work item updates, or scheduled times. This significantly improves efficiency and reduces manual intervention.

Types of Triggers

Azure Pipelines supports several types of triggers:

CI Triggers (Continuous Integration): These triggers initiate a build pipeline whenever a change is pushed to a specified branch in your repository. This is a fundamental aspect of CI/CD.
Release Triggers (Continuous Deployment/Delivery): These triggers automate the deployment of your application to different environments. Common release triggers include:
- Artifact Triggers: A new version of a build artifact becomes available.
- Schedule Triggers: Pipelines run at predefined times.
- Batch Triggers: Grouping of multiple artifact versions for a single deployment.
- Rollback Triggers: Automatically deploy a previous version if a new deployment fails.
Gated Check-in Triggers: Prevent code from being merged into a branch until a build pipeline validates it successfully.
Pull Request Triggers: Trigger builds when a pull request is created or updated to validate the changes before merging.
Scheduled Triggers: Run pipelines at specific times and intervals.

Configuring CI Triggers (YAML Pipelines)

In YAML pipelines, triggers are defined directly within the pipeline definition file. The most common trigger is the CI trigger.

trigger:
  - main  // Trigger on commits to the 'main' branch
  - develop // Also trigger on commits to the 'develop' branch

  branches:
    include:
      - main
      - release/*
    exclude:
      - feature/*

  paths:
    include:
      - src/app/*   // Only trigger if changes are in src/app directory
      - pipelines/*
    exclude:
      - docs/*
      - *.md

Explanation:

trigger: The basic way to specify branches for CI.
branches: Provides more granular control with include and exclude patterns.
paths: Allows you to specify directories or file patterns that should trigger the pipeline. This is useful for monorepos or when only specific parts of the codebase should initiate a build.

Note: By default, if no trigger section is specified in a YAML pipeline, the pipeline will trigger for all branches. Explicitly defining triggers is a best practice.

Configuring PR Triggers (YAML Pipelines)

Pull Request triggers are crucial for code quality. They ensure that changes are validated before being merged.

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

  paths:
    include:
      - src/backend/*
    exclude:
      - tests/*
      - README.md

This configuration ensures that a build is automatically triggered whenever a pull request targeting the main or develop branches is created or updated, provided the changes are within the src/backend/ directory.

Configuring Scheduled Triggers (YAML Pipelines)

Scheduled triggers are useful for nightly builds, periodic cleanups, or re-running failed builds.

schedules:
  - cron: "0 0 * * *"  // Runs daily at midnight UTC
    displayName: Daily midnight build
    branches:
      include:
        - main
      exclude:
        - release/*
    always: true  // Run even if no code changes

  - cron: "0 8 * * 1-5" // Runs every weekday at 8 AM UTC
    displayName: Weekday morning build
    branches:
      include:
        - develop
    always: false // Only run if there are pending changes

Explanation:

cron: Uses standard cron syntax to define the schedule.
displayName: A human-readable name for the schedule.
branches: Allows you to specify which branches the schedule should apply to.
always: If set to true, the job will run on schedule even if there are no new commits. If false, it only runs if there are new commits on the specified branches.

Tip: When defining cron schedules, remember that the time is in UTC by default. You can use online cron expression generators to help create your schedules.

Configuring Triggers in Classic UI Pipelines

For pipelines created using the Classic editor, triggers are configured through the pipeline's UI settings.

Navigate to your pipeline.
Click on the "Edit" button.
For build pipelines, go to the "Triggers" tab.
For release pipelines, select a specific stage and go to its "Pre-deployment conditions" or "Post-deployment conditions" to configure triggers.

You'll find options to enable/disable CI triggers, specify branch filters, configure PR triggers, and set up scheduled triggers with similar parameters as in YAML.

Important: While Classic UI pipelines offer a visual way to configure triggers, using YAML pipelines for defining both your code and your CI/CD infrastructure is the recommended modern approach for its benefits in version control, reusability, and consistency.

Triggers in Release Pipelines

Release triggers are configured per stage in the release pipeline editor:

Artifact triggers: Set up to deploy automatically when a new build artifact is available.
Continuous Deployment trigger: Enable this to deploy every time a new artifact is available.
Schedules: Define specific times to deploy to an environment.
Batch release: Group multiple artifact versions into a single release.

Understanding and correctly configuring triggers is essential for building efficient and responsive CI/CD workflows in Azure DevOps.