Build Pipeline Triggers Using Azure DevOps (CI)

This article demonstrates how to trigger a build pipeline for scheduled continuous integration and pull requests using the Azure DevOps build pipeline trigger.

• The build pipeline triggers tab specifies the events that trigger builds, specify the same build pipeline for CI and scheduled builds.
• Builds are configured by default with a CI trigger on all branches. Control which branch gets triggered with sample syntax.
• Include the branches you want to trigger and then exclude the branches you don't want to trigger.

trigger:
branches:
   include:
   - master
   exclude:
   - develop/*

• In addition to the "define certain branches" in the branches lists, configure triggers based on tags.

trigger:
  branches:
    include:
     refs/tags/{test}

• Disable the CI Builds entirely by specifying trigger: none
• By using the Scheduled trigger, the pipeline is triggered every day or on random days.

Build Completion Triggers

• When a vast number of products have a component that depends on another, these components are often independently built.
• When an upstream service changes (e.g packages), the downstream service has to be rebuilt and revalidated. Usually, people manage these dependencies manually.
• With Azure DevOps, the CI build triggers a build upon the successful completion of another build. Artifacts built by an upstream can be downloaded and used in the later build, and the build will generate variables such as Build.TriggeredBy.BuildId and Build.TriggeredBy.DefinitionId.

Pull Request (PR)

Pull requests are used to review and merge code changes in a git project. A pull request is when teams review code and give feedback on changes before they merge it into the master branch. Reviewers can go through the proposed code changes and comments and approve or reject the code.

• Enable pull request validation under triggers, and specify the branch to merge the code.
• Commits to a file at root repository on a topic branch (developing).
• After committing code into the topic branch, create a pull request.
• Create a pull request, and choose Master branch as the base and compare it as a topic branch. This will compare to the master branch.
  
• Mention title and comments about the pull request, then create a pull request.
• Once the pull request is created, the CI build will automatically start.
• Go through the details, and it will navigate to the Azure DevOps portal. The build will start and run automatically.
• You can view the build with build Id and show a Pull Request build.
• Squash merging keeps the default branch histories clean. When a pull request is completed, merge the topic branch into the default branch (usually Master). This merge adds the commits of the topic branch to the main branch and creates a merge commit to make any conflicts between the default and develop branch.
• When squash merging is done, it is a better practice to delete the source branch.
• The build is triggered through CI (Continuous Integration).
  
• The azure-pipelines.yaml file is shown below:

trigger:
branches:
   include:
   - master
   exclude:
   - develop/*
trigger:
  branches:
    include:
     refs/tags/{test}
     exclude:
      refs/tags/{testapp}
## if dont specify any triggers in the build, mention default one as like below.
trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string
## Batch Building
# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - master
# specific path build
trigger:
  branches:
    include:
    - master
    - releases/*
  paths:
    include:
    - docs/*
    exclude:
    - docs/README.md

# A pipeline with no CI trigger
trigger: none