In Azure DevOps, YAML pipelines provide a way to define your build and release processes as code. One of the key features of YAML pipelines is the ability to specify triggers, which determine when a pipeline should run. Triggers in YAML can be set for various events, such as changes to a specific branch or path in your repository.

Types of Triggers in Azure DevOps YAML Pipelines

1. CI Triggers (Continuous Integration):

   • Automatically trigger a build when changes are pushed to a specified branch.
   • Example:
     yamlCopy code

     trigger: branches: include: - main - feature/* paths: include: - src/* exclude: - src/tests/*

2. PR Triggers (Pull Request Triggers):

   • Trigger a build when a pull request is created targeting specified branches.
   • Example:
     yamlCopy code

     pr: branches: include: - main paths: include: - src/*

3. Scheduled Triggers:

   • Run the pipeline at specified times using a cron syntax.
   • Example:
     yamlCopy code

     schedules: - cron: "0 0 * * *" displayName: Daily midnight build branches: include: - main always: true

Syntax and Options for Triggers

• Branches:

  • include: List of branches to include for the trigger.
  • exclude: List of branches to exclude from the trigger.

• Paths:

  • include: List of paths to include. If any changes occur in these paths, the pipeline will trigger.
  • exclude: List of paths to exclude from the trigger.

• Scheduled Triggers:

  • cron: Defines the schedule using cron syntax (minute, hour, day of the month, month, day of the week).
  • displayName: A friendly name for the schedule.
  • always: Whether to run the pipeline even if there are no source code changes (true or false).

Best Practices

1. Optimize for Efficiency: Configure triggers to only build necessary branches and paths to save resources.

2. Branch Policies: In combination with branch policies, PR triggers can ensure that code changes are built and validated before they are merged.

3. Scheduled Builds: Use scheduled builds for nightly builds or regular validation.

4. Documentation: Document your trigger setup in your repository to make it clear when and why builds are triggered.

5. Testing: Test your trigger configurations in a separate branch before applying them to main branches to ensure they work as expected.

Remember, the trigger configuration plays a crucial role in the efficiency and effectiveness of your CI/CD pipeline, so it’s important to tailor it to the needs of your project.