We have a SonarQube enterprise plan, we have a policy in master branch that waits for the status check of “SonarCloud/quality gate” in AzureDevops with
SonarQube Cloud extension. The PR cannot be merged until this status has green state. We are using dotnet sonarscanner begin&end commands in our build scripts.
I can see the quality gate result in SonarCloud, but it is not reporting back to the PR in DevOps, thus the PR is stuck with the quality gate status check in “Waiting”.
Our organisational level PAT has Code (Read & Write) permissions. And there are no project level PATs.
It’s not a dumb question at all. We don’t use the tasks that come with the extension.
We run the dotnet sonarscanner begin and end commands before and after dotnet build and test. This setup has been working for us, but it recently stopped functioning as expected.
What mechanism are you using to retrieve the Quality Gate status, and make the pipeline wait until it’s actually available?
We could be looking at latency if it used to work but stopped. Quality Gate status isn’t calculated synchronously. The CI submits the analysis report to the server, which queues it and processes it in turn. A small change in the turnaround time could be the difference you’re seeing.
At the Azure DevOps side, we have a status check policy on the master branch that requires the status genre SonarCloud and the status name quality gate. As I understand it, SonarCloud is supposed to set this status in Azure DevOps once the quality gate result is calculated on its side.
However, on the Azure DevOps side, the status is never updated and remains stuck in Waiting.
I am assuming that Sonarcloud is responsible for setting the AzureDevops’s SonarCloud quality gate. Am I right?
Can we check the Sonarcloud logs about this process?
We checked our decoration service logs for your project and found the issue. The ADO binding has the configuration values stored with surrounding single-quote characters — the instance URL is stored as ‘Azure DevOps Services | Sign In’ (note the leading '), which our URL validator rejects, so the decoration step never runs.
"Invalid instance url to decorate the Azure DevOps pull request:
AzureDevOpsSettings{
instanceUrl=''https://dev.azure.com/topkapi-as/'',
projectName=''platform.order'',
repository=''platform.order'',
}"
To fix it, go to your project re-save the ADO configuration. Make sure the values (instance URL, project name, repository) are entered without surrounding quotes — just the bare values, e.g. Azure DevOps Services | Sign In and platform.order.
The PAT itself is fine, so no changes needed there.
Thank you for your reply. Do you want me to rebind the project from the Sonarcloud.io dashboard under Administration > General Settings > Repository binding?
It seems like the repository list is populated via the organization binding. Keep in mind that we have about a hundred projects, so I want to make sure this is the right approach.