4
votes

https://azurecomcdn.azureedge.net/cvt-15581a490a8fb478b3258ea2c0ebb74bfa82fabce2af64ffc38962598949b138/images/page/services/devops/pipelines/github-integrations.jpg

My code repo was in GitHub and my pipelines are configured in Azure DevOps.

I need to let Azure DevOps check and filter every pull request submitted to my GitHub repo and limit the pull request to be merged until it passes Azure DevOps build. It seems that Azure DevOps do supports that. But there was no document nor tutorial about it. How to achieve that?

1

1 Answers

0
votes

You'll need to define a build validation policy for you branches (taken from Improve code quality with branch policies > Build Validation:

  • Select the build definition from the Build definition drop-down.
  • Choose the type of Trigger - either Automatic (whenever the source branch is updated) or Manual.
  • Configure the Policy requirement. If set to Required, builds must complete successfully in order to complete pull requests. Choose Optional to provide a notification of the build failure but still allow pull requests to complete.
  • Set a build expiration to make sure that updates to your protected branch don't break changes in open pull requests.
    • Immediately when branch name is updated: This option sets the build policy status in a pull request to failed when the protected branch is updated. You must requeue a build to refresh the build status. This setting ensures that the changes in pull requests build successfully even as the protected branch changes. This option is best for teams that have important branches with a lower volume of changes. Teams working in busy development branches may find it disruptive to wait for a build to complete every time the protected branch is updated.
    • After n hours if branch name has been updated: This option expires the current policy status when the protected branch updates if the passing build is older than the threshold entered. This option is a compromise between always requiring a build when the protected branch updates and never requiring one. This choice is excellent for reducing the number of builds when your protected branch has frequent updates.
    • Never: Updates to the protected branch do not change the policy status. This reduces the number of builds for your branch, but can cause problems when closing pull requests that haven't been updated recently.
  • Choose an optional Display name for this build policy which is used to identify the policy on the Branch policies page. If you don't specify a display name, the build definition name is used.

Once the configuration is complete, a pull request from GitHub should trigger a build in Azure DevOps.

Hope it helps!