Sonarcloud PR decoration shows waiting in ADO

SonarQube Cloud
1

Hi, The PR check in ADO shows Sonarcloud/quality gate in waiting status.

2

Hi Midhun1909,

Thanks for reporting this. To help us pin down the cause, could you answer a few questions?

  1. Which PR/project? Could you share the project key (or organization) and PR number/link in Azure DevOps?
  2. Is this a first commit or a later one? Did the check work correctly on the PR’s first commit, and only started showing “waiting” after you pushed additional commits, or has it never updated at all, even on the first commit?
  3. When did this start? Was this working before, or has it never worked for this project?
  4. Is this autoscan or CI-based analysis? Is this project set up with Autoscan (no pipeline config needed), or does it run through an Azure Pipelines step with a scanner task?

Once we have this, we can check the analysis logs directly.

Thanks!

Stevan

3

Hi Steven,

Thank you for looking into this,

  1. The project key was mchp-marcom and has been changed to mchp:mchp. The PR decoration was going to Waiting even before changing the key. The Org is mchp-marcom.
  2. The PR decoration is going to waiting status for all the PR starting from 06/26.
  3. It was working before. The PR decoration was setup in 2020 for this project. Where the PAT token has been updated from then whenever it was expired.
  4. This is CI-based Analysis, the sonarscan runs through Azure Pipeline.

My understanding is that after the project key has changed the PR status check(Sonarcloud/quality check) has become stale. And now I dont see an option at the project level to redo it or unbind the project and bind it.

Thanks,

Midhun

4

Hi Steven,

Any update on this?

Thanks,

Midhun

5

Hi @midhun1909,

Looking at both your recent threads together, I think the project key change from mchp-marcom to mchp:mchp around June 26 is most likely the cause. Azure DevOps registers quality gate checks against a specific project key, so when the key changed, the existing branch policy check in ADO lost its reference and got stuck in “waiting” permanently.

A few things to check:

  1. Pipeline YAML: confirm your pipeline is passing sonar.projectKey=mchp:mchp (not the old key). If analysis results are being published under a different key, ADO won’t receive the status update.

  2. Re-register the status check in ADO: go to your repo’s Branch policies → Status checks, remove the old SonarCloud check, and add it back. This re-registers it against the current project key.

  3. Project-level ADO binding in SonarCloud: verify under Project Settings → Pull Requests → Integration with Azure DevOps that the PAT is current and the repository is correctly bound.

On the GitHub options appearing in your settings (from your other thread): that’s because your SonarCloud organization has a GitHub binding at the org level, which causes those options to surface in project settings regardless of the project’s actual platform. It’s not causing the “waiting” issue — it’s just a UI artifact that can be safely ignored.

Hope that helps.

Cheers,

Stevan

6

Thank you Steven for the information shared.

  1. Yes, we have changed the projectKey to mchp:mchp in our pipeline analysis step.
  2. Yes, we have removed and re-registered the SonarCloud check in the branch policy.
  3. Project level binding still shows as Github integration in Pull Requests tab though the integration was with ADO repo. I dont see an option to update the PAT.

image
image798×277 13.6 KB

image
image779×335 17.1 KB

We have only ADO at the Org level binding, we dont have Github

image
image739×390 26.1 KB

Not sure what steps exactly should be followed for an already bound Org/repositories as the document talks more about how to bind.

Please provide a fix or the steps to follow from the scratch to setup PR decoration for an already existing binding.

Thanks,
Midhun

7

Hi @midhun1909,

Thanks for the detailed follow-up. Regarding the GitHub settings you’re seeing in the Pull Requests tab, don’t worry about those. Since your organization is bound to Azure DevOps, those settings don’t apply to you and can be ignored, they would only apply if the Org is bound to Github.

After some further analysis, the issue could be related to your Azure DevOps PAT. There are actually two possibilities here. At some point in the past when project-level PAT configuration was still available in the UI you may have set a project-level Azure DevOps token: sonar.pullrequest.vsts.token.secured. That setting is no longer visible, but it’s still there in the background and takes precedence over your organization-level binding PAT. This could be one reason why the quality gate status never gets posted back to ADO.

The fix is to clear that hidden setting via the API. You’ll need admin permissions on the project to do this.

Make a POST request to:

https://sonarcloud.io/api/settings/reset

With the following parameters:

keys=sonar.pullrequest.vsts.token.secured
component=mchp:mchp

For example, using curl:

curl  -X POST "https://sonarcloud.io/api/settings/reset" \
  --data "keys=sonar.pullrequest.vsts.token.secured&component=mchp%3Amchp" --header 'Authorization: Bearer <SQC_TOKEN>'

Once that’s done, trigger a new PR analysis and the quality gate status should be posted back to Azure DevOps correctly.

If the issue persists after clearing the project-level token, it’s worth double-checking that your organization-level PAT is still valid. You can review and update it under SonarQube Cloud Organization > Administration > Organization Settings > Organization binding > Replace Token, where you’ll find the Azure DevOps Binding section with an option to enter a new token. Make sure the PAT has at minimum the Code (Read & Write) and Analytics (Read) scopes, and that the ADO user who generated it has at least Basic access level and Contributor permissions on the relevant repositories.

Let us know how it goes!

Cheers,

Stevan

8

Clearing the token worked. Thank you Stevan.