Set up build validation for pull requests in Azure Repos as a branch policy on the target branch and link an appropriate pipeline from Azure Pipelines there. This checks, before a pull request is completed, whether the proposed change passes the defined pre-merge validation. If the policy is set as required, the merge remains blocked until there is a valid successful run.
This setup is one of the key protection mechanisms in Azure DevOps Services when changes should not only be reviewed, but also technically validated before merge. What is meant here is the automatic validation of a pull request against the target branch, not a normal run after the merge.
This article focuses on the few settings that really matter:
- selecting the target branch
- assigning the right pipeline
- the difference between optional and required
- handling expiring build results when the target branch changes
What build validation does in pull requests
In Azure Repos, build validation is a branch policy. Branch policies always apply to the target branch of a pull request, in other words the branch into which the merge is intended.
The timing is important: the assigned build does not run only after the merge, but already before the pull request is completed. This means the proposed change is checked in exactly the process your team has defined for it in Azure Pipelines.
In practice, this is a technical minimum check. Typical examples include:
- a successful build
- automated tests
- additional pipeline steps that are deliberately kept lightweight for pull requests
Build validation sits alongside other policies. These include, for example, a minimum number of reviewers, linked work items, comment resolution, status checks, required reviewers and rules on merge types. According to Microsoft, these policy types are disabled by default. Source: Microsoft Learn, Branch policies overview, accessed on 01.11.2026.
For important branches such as main, Microsoft recommends in its security baseline, among other things, build validation, at least two reviewers, linked work items, comment resolution and automatically included reviewers for sensitive paths. Source: Microsoft Learn, Securely use repositories and pull requests, accessed on 01.11.2026.
Build validation therefore does not replace a functional review or a manual code review. It adds an extra technical gate before merge. You can also see how these rules work together in our article on other branch policies.
Setting up build validation in the branch policy
Set up the policy directly on the target branch, not on the source branch. In the repository, open the branch you want to protect and enable Build validation there. A target branch is the branch into which the pull request is intended to be merged.
Then assign exactly one suitable pipeline from Azure Pipelines. A pipeline suited to this policy is one designed for the pull request case: clearly scoped, reproducible and without steps that add nothing to pre-merge validation. What matters is not breadth so much as reliability.
When choosing the pipeline, three practical questions help:
- Does it check the state of the code that matters before completion?
- Does it provide understandable feedback when it fails?
- Does it fit this specific target branch rather than just the repository in general?
At this point, you also decide whether the policy should be mandatory or merely informative. Its real effect in the team therefore depends not only on the pipeline, but on the combination of branch, pipeline and mandatory status.
Microsoft lists build validation as its own policy type alongside other rules such as linked work items, required reviewers and comment resolution; all these policy types are disabled by default. Source: Microsoft Learn, Branch Policies overview, accessed on 01.11.2026.
If you want to complement the process cleanly, these often fit well: creating pull requests properly, linking work items with pull requests and using required reviewers selectively.
Understanding triggers, mandatory status and build expiration correctly
What matters here is not so much whether it runs, but when. The policy should not assess just any earlier run, but the state that is currently awaiting approval in the pull request.
For how the team experiences it, three switches matter most:
- when validation is required again
- whether the result is merely visible or binding
- how a success that has since become outdated is handled
Mandatory status is what separates a hint from a block. If the policy is required, the pull request can only be completed once there is a valid successful run. If validation is missing, fails or has expired, completion remains blocked.
Build expiration controls precisely this last case. It does not automatically treat an earlier successful run as permanently valid. This is especially useful if the target branch has moved on in the meantime and the old result no longer properly covers the current integration state.
It is also worth looking at exceptions. Microsoft recommends granting the permissions Bypass policies when completing pull requests and Bypass policies when pushing only to a small admin group. Source: Microsoft Learn, Securely use repositories and pull requests in Azure Repos, accessed on 01.11.2026.
If you want to trigger reactions to changes in the pull request, for example on new commits or on completion, events via service hooks are a good fit.
How to keep validation practical and lean in day-to-day use
In day-to-day work, build validation rarely fails because of the policy itself, but because a pipeline is trying to do too much at once for pull requests. For this pre-merge step, what matters above all is that the validation is clear: the same process, a clear outcome and an understandable failure.
A simple separation helps:
- What must definitely be checked before merge?
- What can move to a later run?
- Which steps create load but add hardly any extra insight?
This helps you avoid every small change triggering the same heavy process again.
Also pay attention to the form of the feedback. Validation only helps during review if, when it fails, it is quickly clear whether the cause is a test, a build step or a configuration issue. Otherwise, a protection measure quickly turns into a search exercise.
The size of changes matters just as much. Small, focused pull requests are not only easier to review, they also make build results easier to read. A pull request is a proposed change with discussion, validation status and a merge target all in one process.
You should decide the policy on merge types separately from this. In “Securely use repositories and pull requests in Azure Repos”, Microsoft describes it as governing history rather than being a direct security control; for audit models that require an exact commit sequence, Microsoft points to merge-commit strategies rather than squash, accessed on 01.11.2026.
What is often discussed as well today: reviews, AI and data questions
Alongside build validation, many teams are discussing automated review suggestions. That is a separate building block: build validation checks a defined pipeline run before merge, while an AI review adds comments in the pull request.
For Azure Repos, one point matters here: according to Microsoft, Copilot code review has been available in Public Preview without sign-up since Sprint 279 and can be enabled per organisation, project or repository. It can also be triggered automatically via branch policies. Preview means: no SLA, and changes are possible. Source: Microsoft Learn, “Sprint 279 Update” and “Copilot code reviews”, accessed on 01.11.2026.
For assessing it, three points matter above all:
- It always leaves a Comment review.
- It therefore does not satisfy a Required reviewer policy.
- It does not itself block a merge.
Source: Microsoft Learn, “Review pull requests” and “Copilot code reviews”, accessed on 01.11.2026.
It is worth taking a close look at data questions. According to Microsoft, the data residency of Copilot code review does not correspond to the data residency boundaries of your Azure DevOps organisation; processing may therefore take place in a different geography even for EU-hosted organisations. Source: Microsoft Learn, “Copilot code reviews FAQ”, accessed on 01.11.2026.
If you are assessing such functions in regulated environments or those with co-determination requirements, the questions often concern data protection, DORA, NIS2 and co-determination. Clarify this with your legal department, a solicitor or your data protection officer.
Frequently asked questions about build validation
Does build validation apply repository-wide?
No. It is attached to the target branch. That allows you to define deliberately different checks for main, release branches or integration branches, instead of using a single rule for everything.
This is particularly useful where risks and approval paths differ. A branch with frequent releases often needs a different pre-merge check from a branch used for ongoing integration.
Who may bypass failed or missing validation?
This is not a question of build validation alone, but of permissions. In its security baseline for important branches, Microsoft recommends granting the rights Bypass policies when completing pull requests and Bypass policies when pushing only to a small admin group. Source: Microsoft Learn, “Securely use repositories and pull requests in Azure Repos”, accessed on 01.11.2026.
For teams, this is above all a governance issue:
- Who may make exceptions?
- When is that permissible?
- How is the case documented?
Can the setup also be automated?
Yes. According to Microsoft, branch policies can be set not only in the user interface, but also with az repos policy commands or via the REST API. Source: Microsoft Learn, “Branch policies” and “Branch policies overview”, accessed on 01.11.2026.
If you want to manage or evaluate pull request rules by script, the article on pull requests via the REST API will help.
When is a pull request in draft state useful before validation?
When a change is not yet intended for approval, but should already be visible. A draft pull request is a pull request that is not yet intended for completion. This fits, for example, where there are open architecture questions or unfinished tests.
For this intermediate state, the article on draft pull requests is a good fit.
Where does automation around pull requests fit in here?
For completion, the decisive factor remains the branch policy on the target branch. If you are interested in more extensive automation: Polier is in development and not available.
Next step
Set a fixed validation path for your most important target branch and then, in day-to-day work, check only two questions: does the policy trigger at the right moment, and does the result remain valid until merge?
A short checklist helps with team alignment:
- Which pipeline is intended only for pull requests?
- When should a result expire?
- Who may make exceptions to policies at all?
- Which questions concern data, identities or guardrails?
For these surrounding topics, you can find the current position on security and data questions, notes on subscription and sign-up at the development stage and the future page for measured results from real runs.
Polier by ballmüller solutions, Berlin, is in development and not yet available.