Azure DevOps Services and Server · Branch policies · October 26, 2026

Azure DevOps build validation: expired builds, manual queue, and why a pull request build did not run

A Build validation policy on a branch makes the pull requests into it build with a pipeline before they can be completed. In Azure Repos Git it is also the only way to run a pipeline for a pull request: a pr: trigger in the YAML file does nothing there. Below is how the policy works, what makes its build expire, and how to queue it again, from Microsoft's Set and manage branch policies, Build Azure Repos Git repositories and the REST reference for Requeue Policy Evaluation.

The settings

• Build pipeline: the pipeline to run. It has to exist before you add the policy. XAML build definitions cannot be used, and Microsoft notes that setting up validation builds takes a project administrator.
• Path filter (optional): the policy applies only when the pull request changes matching files. A path that does not start with / or a wildcard has no effect.
• Trigger: Automatic (whenever the source branch is updated) queues a build when the pull request is created and on every push to it. Manual leaves queueing the build to the people on the pull request. Either way the policy reads the build result.
• Policy requirement: Required builds must succeed before the pull request can be completed. Optional builds report a failure but do not block it.
• Build expiration: what an update to the target branch does to a build that already passed (below).
• Display name (optional): how the policy is named on the pull request; without one, the pipeline's name is used.

What the build runs on

• The policy's pipelines build the merge commit: the code you would get by merging the source branch into the target branch.
• They run even when a pushed commit says [skip ci]. That marker only stops the pipelines triggered by pushes to the source branch itself.
• The YAML file read for a pull request build is the one from that merge, not the one on either branch alone.

Why the pull request build did not run

• It is in the YAML file. For an Azure Repos Git repository a pr: trigger in YAML is not used; Microsoft's troubleshooting says to use branch policies instead. (The YAML schema says pr: triggers are supported only for GitHub and Bitbucket Cloud.)
• The pull request is a draft. Draft pull requests do not trigger a pipeline even with a build validation policy; it starts when the draft is published.
• The trigger is Manual. Someone has to queue the build. Until then the policy waits.
• The path filter does not match the changed files, or a path in it does not start with / or a wildcard and so never matches.
• The pipeline is paused or disabled in its settings; its triggers do not work then.

Expired builds

• Immediately when <branch> is updated: every update to the target branch sets the build policy to failed and queues a new build. Safest, but busy branches wait for many builds.
• After <n> hours if <branch> has been updated: when the target branch is updated, a passing build older than n hours expires.
• Never: updates to the target branch do not change the result. Fewest builds, but a pull request that has not been updated for a while can be completed on a stale result.
• An expired required build blocks completion and auto-complete until it passes again. If the build was not queued again by itself (with a Manual trigger, for example), queue it again from the pull request, the command line or the API.

Queueing it again from the command line and the REST API

• az repos pr policy list --id <pr> --output table lists the pull request's policies with their Evaluation ID, status, an Expired column and the build ID.
• az repos pr policy queue --id <pr> --evaluation-id <evaluation-id> queues that policy's evaluation again. The Azure DevOps CLI is not supported for Azure DevOps Server.
• In the REST API, PATCH …/_apis/policy/evaluations/{evaluationId} with the status set to queued requeues an evaluation (scope Code (Read & write)). Microsoft notes that only build policies do anything in response, and that requeueing one queues a new build, cancelling a build that is still running.

Build validation in IntelliJ IDEA

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, lists the pull requests of Azure DevOps Services and Azure DevOps Server in an IDE tool window with their branch policies in plain words. A build policy shows its display name and whether it passed, failed, is running, is waiting or has expired, with optional policies marked. With Pro, a build that failed, expired or was never started (a Manual trigger) has a Run again link that queues it through the same REST call. The review inbox and the branch policies are free; voting, commenting, completing, running a build policy again and creating pull requests are Pro, with a 30-day trial.

Get it on JetBrains Marketplace

Azure DevOps is a trademark of Microsoft Corporation; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft or JetBrains.

More: status checks from other services · comment status and the comment resolution policy · auto-complete and optional policies · draft pull requests · required reviewers and path filters · explicit override to bypass policies · 日本語