I am using Azure DevOps YAML pipelines and have two stages – one is deploying to dev (is triggered by commit in master), and the second is checking pull requests (running tests and static analysis). These stages are executed based on variables, e.g. variables['Build.Reason'] or variables['Build.SourceBranchName'].

The pull request checks are set as required in branch policy, so the pipeline must pass before the author can merge it.

What I want is to allow the author to manually trigger deploy to dev from pull request (e.g. because there are changes in infrastructure, environment variables, etc.) to make sure everything works before the changes are merged upstream.

What I tried so far

• Using ManualValidation@0 task: not applicable, because then the pipeline is not successful. As the pipeline is required to pass before the merge request, the author can’t merge it without the deployment to dev.
  I didn’t try deployment jobs, but I suspect these work similarly.
• Use parameter, like DeployDevFromPR, that should indicate whether the pipeline should check to code, or deploy it. Then set two branch policies, one automatic and required (the checks) and one manual and optional (the deployment). However, there is no possibility to set the env variable from the PR view (unless the author requeue the pipeline again), so the manual step runs the check.
• Decide based on variable variables['Build.QueuedBy']: the value is different when pipeline is triggered automatically. For user, there is its username, but for automatic triggers there is “Microsoft.VisualStudio.Services.TFS”. However, this breaks if the user wants to rerun the check pipeline (then the QueuedBy will be the user).

Can I somehow get to the desired effect to allow user deploy from PR manually without blocking the merge?

Thank you