Azure DevOps comment status and the comment resolution policy
Every comment thread on an Azure Repos pull request has a status. With the Check for comment resolution branch policy, those statuses decide whether the pull request can be completed. Below are the statuses, what the policy checks and where it usually gets stuck, from Microsoft's Review pull requests, Set and manage branch policies and the REST reference for Pull Request Threads - Update.
The statuses
- Active (
active): the status every new comment starts with. - Pending (
pending): the issue is under review and waits for something else. - Resolved (
fixed): the issue is addressed. Reply & resolve sets this status in one step. - Won't fix (
wontFix): the issue is noted but will not be fixed. - Closed (
closed): the discussion is closed. - By design (
byDesign): in the REST API, "resolved as by design". Microsoft's current page does not list it among the statuses the web dropdown offers, but a thread can still have it.
Microsoft describes the pull request's author changing the status to show how each piece of feedback was handled. In the REST API's descriptions, fixed, wontFix and byDesign are "resolved as" something and closed is closed; active and pending are not resolved.
The Check for comment resolution policy
- Turn Check for comment resolution on in the target branch's policies, then make it Required or Optional. It checks whether all the pull request's comments are resolved.
- A Required one keeps the pull request from being completed, and auto-complete from finishing, while comments are still open. An Optional one only reports it.
- From the command line:
az repos policy comment-required create --blocking true --branch main --enabled true --repository-id <id>;--blockingis the Required switch. In policy evaluations its type is named Comment requirements.
Why the policy still fails
- A thread is Pending. Pending means it waits for something else, not that it is resolved. Set it to Resolved, Won't fix or Closed when the point is settled.
- An open thread is out of sight. The comment filter on the Overview tab narrows the discussion, and each option shows how many items it has. Comments on files are threads too.
- The reviewer is waiting for an answer. Reply to the comment and resolve it, rather than resolving it silently, so the reviewer knows how it was handled.
- Someone with permission to bypass policies sees the failure too, but for them it is advisory only, as with every policy.
Setting a status with the REST API
GET …/_apis/git/repositories/{repository}/pullRequests/{id}/threadslists the threads with theirstatus.PATCH …/pullRequests/{id}/threads/{threadId}with{"status": "fixed"}resolves one (scope Code (Read & write));activereactivates it.
Comment resolution 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. Each pull request shows its comment threads with their status in your IDE's language, the count of open (Active or Pending) and resolved ones, resolved threads folded away behind Show resolved, and the policy row All comments resolved with the other branch policies. In the diff, a thread's icon beside the code shows whether it is resolved. With Pro you can reply to a thread, Resolve it and Reactivate it from the pull request's comments. The review inbox and the branch policies are free; voting, commenting, resolving, completing 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: the linked work items policy · build validation and expired builds · auto-complete and optional policies · why an approval does not count · explicit override to bypass policies · what changed since your last review · 日本語