Azure Devops Status check configuration with reset status breaks analysis

SonarQube Server / Community Build
, ,
1

Must-share information (formatted with Markdown):

  • SonarQube version 2026.1 (Developer Edition)
  • Deployed via Docker in a Kubernetes cluster

We would like to have status check in Azure DevOps for SonarQube and everything works fine, until we enable “Reset status whenever there are new changes”.

PNG image
PNG image948×1390 79.4 KB

We want to enable this to ensure the latest push is analysed. Unfortunately the analysis fails with the following message when trying to publish the status check:

Pull Request decoration failed: Unable to contact Azure DevOps Server: Pull request status rejected by status policy. Policy configuration requires status to be posted on iteration

This is due to the fact that the request that is being sent Azure is missing the iterationId in the body. The iterationId should be requested, in addition to the PullRequest information.

2

Hi,

It sounds like SonarQube can’t talk to your ADO instance. The docs should help.

 
Ann

3

Hi Ann,
we are also facing an issue, if a new commit is pushed to the PR the ci builds are getting success but the status checks kept waiting when Reset status whenever there are new changes is checked. You kept asking why use reset toggle and not provided proper solution in this topic

why develop that option?

image
image374×417 13.4 KB

4

Hi @Suvishesh,

Welcome to the community!

Have you checked the docs I referenced above? Have you checked your server logs?

 
Ann

5

It can definitely talk to Azure DevOps. It simply leaves out the iterationId in the request from SonarQube. If we would disable “Reset status whenever there are new changes” it does work.

6

Hi @sebastiaanspeck,

Could you elaborate on this? And what do your server logs say?

 
Thx,
Ann

7

The logs show somewhat the same like: Pull Request decoration failed: Unable to contact Azure DevOps Server: Pull request status rejected by status policy. Policy configuration requires status to be posted on iteration.

SonarQube should do an extra request to retrieve the current PR iterationId (Pull Request Iterations - List - REST API (Azure DevOps Git) | Microsoft Learn) which should be added to the request body of Pull Request Statuses - Create - REST API (Azure DevOps Git) | Microsoft Learn

8

Hi,

You’ve previously said that SonarQube can talk to ADO. Do other entries in the server log before and after this^ indicate that?

You think it’s not that SonarQube can’t talk to ADO but that ADO is rejecting the request?

 
Thx,
Ann

9

The message we get is a bit weird. It can talk to ADO, but ADO rejects the request due to the missing iterationId.

Exactly! The request is missing an important detail if you enable “Reset status whenever there are new changes” in ADO.

10

Hi,

Thanks for clarifying. I’m going to flag this for the team. Unfortunately, they’re facing resource constraints at the moment, so I’m not sure when they’ll be able to take a look.

 
Ann

15

Hello @sebastiaanspeck

Sorry for the late response and thank you for your patience!

After investigating this further, we found that this issue can occur in certain pipeline configurations where the SCM revision used during analysis doesn’t match what Azure DevOps expects. This can happen for example when running the scanner inside a Docker container without access to the .git directory, custom checkout steps, or other non-standard pipeline setups.

If you could share some details about your setup, it would help us confirm which specific scenario applies to your case:

  1. How are you running the scanner? (Azure DevOps task, CLI, Maven/Gradle plugin, custom Docker step?)
  2. Are there any custom git operations before the scanner runs? (checkout steps, rebase, merge, etc.)
  3. Your pipeline YAML or the relevant prepare/analyze steps would be great to see if you’re able to share

In the meantime, I’ve added a ticket to add a fallback on our side. As a temporary workaround, you can pass sonar.pullrequest.vsts.iterationId to a scanner - you have to fetch iteration id yourself though.

Thanks!