How to execute Build Task only after PR has been reviewed and approved?

Question

I may have some expensive tasks/tests and a PR that has not been reviewed could require additional changes.

I don't want to run those expensive tasks for every commit or minor change but only after such changes have been reviewed and approved.

These tasks might not only be expensive to run, but they might also have some run quotas. Moving to a CI build is not desirable given it means that code that breaks the app could get into master and it would require an additional PR to fix.

Is it currently possible in Azure DevOps? How?

Soldier

Hi mdarefull, Does my answer help? Please check it and kindly let us know the result. Thanks. – Vaginitis

The answer looks good and it makes total sense... I haven't been able to validate it though, we are prioritizing other tasks. Thank you so much for the quick response, I will validate and notify you ASAP – Soldier

Hi mdarefull, How about this issue? Does my answer help? I am lookin forward to hearing from you. Thanks. – Vaginitis

Answer 1

If you call this Rest API: Pull Requests - Get Pull Request By Id, the response body will return reviewers array which contains reviewers information. If there is one reviewer approve(or approve with suggestions) this pull request, the value of vote for this reviewer is positive integer, otherwise it is negative integer. Thus this vote property can be used as the flag to check if this pull request is approved or rejected by required reviewers.

Therefore, you could use PR triggers instead of CI triggers, and add a PowerShell task before running those expensive tasks by specifying conditions. And the PowerShell task will run script using above Rest API to check if this pull request is approved and return the result to be the value of flag variable(isApproved), so the flag variable can be passed in those expensive tasks when specifying custom conditions like and(succeeded(), eq(variables['isApproved'], 'true')).

Vaginitis

This does not work for all cases. Imagine that someone creates a PR and it needs no modifications. Hence, all reviewers would just approve the pull request and the script would not be called! – Promotive

@Promotive the script would be called as part of a pipeline run from a PR trigger; so the PR cannot be completed without running the pipeline. – Fraser

Answer 2

The general approach to running tasks after a PR Approval is to automate those tasks on the target branch, not the source one. The end result of your PR approval is to commit the merge so this makes a lot of sense.

If you are worried about affecting the master branch then you should use an interim/approval/staging/testing branch before going to master, this branch would have the pipeline trigger.

• This has an additional benefit to reducing costs by allowing you to consolidate multiple PRs that have been approved for testing
• This is a basic concept of GitFlow (Feature) branch style

It sounds like you want some of the features from GitFlow but you are using Trunk-based branching.

Slackjawed