Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Build Pipeline Triggers Using Azure DevOps (CI)

DZone 's Guide to

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.

Free Resource

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.Continuous Integration
  • 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/*

CI-branch specification

  • 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.Image title

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.Image title

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.Image title
  • Commits to a file at root repository on a topic branch (developing).Image title
  • After committing code into the topic branch, create a pull request.Image title
  • 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.
    Pull request validation
  • Mention title and comments about the pull request, then create a pull request.Image title
  • 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.Image title
  • You can view the build with build Id and show a Pull Request build.Image title
  • 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.Image title
  • When squash merging is done, it is a better practice to delete the source branch.Image title
  • The build is triggered through CI (Continuous Integration).
    Image title
  • 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
Topics:
azure devops ,devops ,continious integration ,yaml ,build pipeline trigger ,tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}