Reputation: 151
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
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
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.
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.
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
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:
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.
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
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:
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