How to fix TF401027: You need to resolve policy violations before completing this pull request in Git

First, determine exactly which policies haven't been satisfied:

1. Navigate to your pull request in Azure DevOps
2. Look at the Policies section on the PR overview page
3. Each policy shows a status icon:
- Green checkmark: Policy satisfied
- Red X: Policy violated/failed
- Yellow clock: Policy waiting/pending
4. Click on any failing policy to see details

Common policy types you'll see:
- Minimum number of reviewers: Shows current approval count vs required
- Build validation: Shows build status (passed/failed/pending)
- Work items: Shows whether work items are linked
- Comment resolution: Shows unresolved comment threads
- Required reviewers: Lists specific people who must approve

Note the specific violations—you'll address each one in the following steps.

If the minimum reviewer policy isn't satisfied:

Request reviews from team members:
1. On the PR page, click Reviewers in the right panel
2. Add team members who can review your changes
3. Optionally add a message explaining what to review
4. Wait for reviewers to approve

Reviewer options:
- Approve: Counts toward minimum reviewers
- Approve with suggestions: Still counts as approval
- Wait for author: Doesn't count until author addresses feedback
- Reject: Blocks completion (reviewer must change vote)

If reviews are stalling:

# Send a reminder via Azure CLI
az repos pr reviewer add --id <PR_ID> --reviewers <[email protected]>

Tips:
- Check if your organization has auto-assigned reviewers
- Some teams require specific code owners to approve
- A single rejection may block completion depending on policy settings

If build validation is failing:

Check the build status:
1. Click on the failing build in the Policies section
2. Review the build logs to identify the failure
3. Common failures include:
- Compilation errors
- Unit test failures
- Code coverage below threshold
- Linting/static analysis issues

Fix the issues and push:

# Make necessary fixes locally
git add .
git commit -m "Fix build failures"
git push origin <your-branch>

The build will automatically re-run when you push new commits.

If the build is stuck or hasn't run:

# Trigger a new build via Azure CLI
az pipelines run --name "<pipeline-name>" --branch <your-branch>

# Or re-queue build validation from the PR
# Click "Re-run" next to the build policy

If the build passes locally but fails in Azure DevOps:
- Check environment differences (Node version, OS, etc.)
- Verify all dependencies are committed or in package manager
- Look for flaky tests that pass intermittently

If work item linking is required:

Link from the PR interface:
1. On the PR page, find the Work items section
2. Click Link work item or the + button
3. Search for the work item by ID or title
4. Select the appropriate link type (usually "Resolves" or "Related")

Link using commit messages:
Include work item IDs in your commits:

# Azure DevOps recognizes these patterns
git commit -m "Fix authentication bug #1234"
git commit -m "Implement feature AB#5678"
git commit -m "Resolves: #1234"

Link via Azure CLI:

# Link a work item to your PR
az repos pr work-item add --id <PR_ID> --work-items <WORK_ITEM_ID>

If no relevant work item exists:
- Create a new work item (Bug, Task, or User Story)
- Ask your project manager which work item to link
- Check if your team has a backlog item for this work

If comment resolution is required:

Find unresolved comments:
1. Go to the Files tab in your PR
2. Look for comment indicators on changed lines
3. Or click Comments to see all threads

Resolve comments:
- Reply and resolve: Address the feedback, then click "Resolve"
- Won't fix: If you disagree, explain why and resolve
- Ask reviewer to resolve: Some teams require the commenter to resolve

Best practices:

When addressing feedback:
1. Make the requested code change
2. Push the commit
3. Reply to the comment with what you changed
4. Click "Resolve" on the thread

Bulk resolve (use carefully):
If there are many resolved discussions that weren't marked:
- Use the "Resolve all" option if available
- Or go through each thread systematically

Note: Active/unresolved comments are different from "Won't fix" comments. Even "Won't fix" should be marked as resolved with an explanation.

Some policies require specific people or groups to approve:

Identify required reviewers:
1. Check the Required reviewers policy in the PR
2. See which specific reviewers haven't approved yet
3. These might be:
- Code owners for modified files
- Security team for sensitive changes
- Team leads or architects

Reach out directly:
- Send a Teams/Slack message to the required reviewers
- Explain the urgency if applicable
- Offer to walk through the changes

If a required reviewer is unavailable:
Contact your project administrator to:
- Temporarily modify the branch policy
- Grant you bypass permissions (if appropriate)
- Reassign the required reviewer role

Using Azure CLI:

# Check PR status including reviewer details
az repos pr show --id <PR_ID> --query "reviewers"

# List who's required vs optional
az repos pr policy list --id <PR_ID>

Some policies require your branch to be current with the target:

Check if this policy applies:
Look for "Check for linked work items" or "Require branches to be up to date" in policies.

Update your branch:

# Fetch latest changes
git fetch origin

# Merge target branch into your feature branch
git checkout your-feature-branch
git merge origin/main

# Resolve any conflicts if they occur
# Then push the updated branch
git push origin your-feature-branch

Or rebase (cleaner history):

git checkout your-feature-branch
git fetch origin
git rebase origin/main

# Force push after rebase
git push --force-with-lease origin your-feature-branch

Note: After updating, build validation will re-run automatically. Wait for it to pass before attempting completion again.

If you have bypass permissions and the situation warrants it:

Complete with override:
1. On the PR page, click the dropdown arrow next to "Complete"
2. Select "Complete (override)" or look for bypass options
3. You may need to provide a reason for the override
4. Click Complete to merge despite policy violations

When bypassing is appropriate:
- Emergency hotfix for production issues
- Approved exception from project leadership
- Policy is incorrectly configured
- External dependency causing false failure

When NOT to bypass:
- To avoid doing a proper code review
- Because the build is "probably fine"
- Without understanding why the policy exists

Check if you have bypass permission:

# Via Azure CLI - check your permissions
az devops security permission show --namespace-id <REPO_NAMESPACE> --subject <YOUR_ID>

Request bypass permission:
Contact your Azure DevOps administrator to grant:
- "Bypass policies when completing pull requests"
- "Exempt from policy enforcement"

These permissions are in: Project Settings > Repositories > Security

Once all policies are on track to pass, enable auto-complete:

Enable auto-complete:
1. On your PR, click Set auto-complete
2. Configure merge options:
- Merge type (merge, squash, rebase)
- Delete source branch after merge
- Complete associated work items
3. Click Set auto-complete

The PR will automatically complete once all policies pass.

Auto-complete behavior:
- Waits for all required approvals
- Waits for build validation to succeed
- Waits for any external status checks
- Won't complete if new commits are pushed (must re-enable)

Using Azure CLI:

# Enable auto-complete on a PR
az repos pr update --id <PR_ID> --auto-complete true

# Set merge strategy
az repos pr update --id <PR_ID> --merge-type squash

Note: Auto-complete won't bypass policies—it just waits for them to pass. If a policy cannot pass, you'll still need to address it manually.