Markus Peterson
Markus Peterson

Reputation: 151

How to run Azure Pipeline only after PR has been approved?

Just as the title says,

I would like to have a PR workflow in which my pipeline starts running only after someone approved my PR in Azure Repos.

Everything is inside Azure DevOps.

Upvotes: 0

Views: 78

Answers (3)

Vimal Patel
Vimal Patel

Reputation: 119

To trigger the pipeline only after PR approval, you can use Branch Policies with a manual Build Validation step. However, since manual validation doesn’t automatically start after approval, a workaround is needed.

Alternative Approach: Enable Build Validation but keep it automatic (trigger on PR). Use Conditional Execution inside your pipeline to check PR approval status before proceeding.

A way to achieve this is by using Azure DevOps REST API inside your pipeline to check if the PR is approved before running the actual build steps.

Upvotes: 0

wade zhou - MSFT
wade zhou - MSFT

Reputation: 8470

I would like to have a PR workflow in which my pipeline starts running only after someone approved my PR in Azure Repos. Everything is inside Azure DevOps.

The pull request build validation doesn't support to trigger the pipeline only when specific user approved PR.

You can use the Webhook and Resource Webhook trigger in Azure Pipeline. Here are the steps:

Step1: Create a new user group in Project settings -> Permissions page, add your target approver as the member.

enter image description here

Step2: Create a webhook in Project Settings -> Service hooks -> Webhook.

event type: Pull request updated

repository(if needed): target repo

Change: Votes score changed

For Requested by a member of group: choose the group created in step1, so that it will monitor on the target approver.

For example: enter image description here

You can set the Webhook URL:

https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview

In this case, when the Pull Request is approved by the user, it will trigger the Webhook.

Step3: Create an Incoming Webhook in Project Settings-> Service Connections. Refer to this doc: Generic webhook based triggers for YAML pipelines

enter image description here

Step4: You can disable the CI trigger(trigger: none) and setup the Webhook trigger in Pipeline.

trigger: none
resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebHookConnection    ### Incoming webhook service connection

steps:
- script: |
    echo "${MY_JSON}"
  env: 
    MY_JSON: ${{ convertToJson(parameters.MyWebhookTrigger) }}    # check the payload

- script: |
    echo ${{ convertToJson(parameters.MyWebhookTrigger.message.text) }}

The webhook and pipeline is triggered as expected:

enter image description here

enter image description here

You can also use filter for DevOps webhook trigger, but need to match exact payload value which contains the approver, eg: message.text. But it could limit to specific pull request, the group method suggested above could be better for your situation.

enter image description here

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebHookConnection    ### Incoming webhook service connection
      filters:
        - path: message.text
          value: "waXX zXXou approved pull request 375 (Updated README.md) in test4\r\nhttps://dev.azure.com/XXXXXXXk/_git/test4/"

Upvotes: 0

bryanbcook
bryanbcook

Reputation: 18328

If you’re looking to run the build validation pipeline associated with your branch policy after someone has provided an approval but before the pull request has been completed, there isn’t anything native in the branch policy to do this. Normally, we use build validation as part of a branch policy to test our changes before the code is merged. Once it is merged, the CI trigger for the target branch executes. If there is something in your pipeline that is sensitive and should only be executed after an approval, I would consider moving those sensitive elements to the target branch CI.

There are a few possible workarounds to accommodate what you’re asking for.

Conditional Pipeline

You could add conditional logic to your pipeline to only perform certain tasks if approval has been provided. For example, use the Azure DevOps REST API to query the details of the pull request, examine the status of the required approvals and then fail the build if the conditions aren’t met.

This strategy will satisfy the build validation policy of the branch policy, but it will need to be triggered manually.

Trigger Pipeline using Incoming WebHook

For YAML-based pipelines, as outlined in this answer, it is possible to trigger a pipeline based on a WebHook. At a high level, the answer outlines:

  1. Create an “Incoming WebHook” Service Connection.
  2. Create a Service Hook that calls the Incoming WebHook based on the pull request updated event. The settings of this hook can be customized to only trigger when the pipeline votes have changed.
  3. Define a WebHook resource in your pipeline that uses the Incoming WebHook service connection as the trigger.

In this scenario, the payload of the pull request is available as a pipeline variable so you won’t need to use the REST API to query the pull request details, but you will need a script to inspect the payload because the event is triggered when votes are approved, rejected, reset, or the approver isn’t one of the required approvers.

Another key consideration is this strategy won’t satisfy the build validation policy of the branch policy because it is not triggered directly by the pull request. Instead of using a build validation setting, you can define a Custom Status in the branch policy, and use the REST API to send a success/fail custom status message to the pull request as a last step in your pipeline.

There are other considerations, such as concurrency (what happens when multiple votes are received in rapid succession) and resetting the custom status every time the pipeline executes.

Upvotes: 0

Related Questions