Hi, I have the same issue, but in my case the PR was raised before the analysis (I used branch policies in ADO to trigger PRs), and a SonarCloud analysis had previously been run successfully, but now it keeps failing with the same error.
```log
##[error]11:02:59.826 ERROR Could not find the pullrequest with key 'XXXX'
11:02:59.826 ERROR Could not find the pullrequest with key 'XXXX'
11:03:00.154 INFO EXECUTION FAILURE
11:03:00.156 INFO Total time: 12.913s
##[error][ERROR] SonarQube Cloud: Error while executing task Analyze: The process '/home/vsts/work/_tasks/SonarCloudAnalyze_ce096e50-6155-4de8-8800-4221aaeed4a1/4.2.6/sonar-scanner/bin/sonar-scanner' failed with exit code 3
##[error]The process '/home/vsts/work/_tasks/SonarCloudAnalyze_ce096e50-6155-4de8-8800-4221aaeed4a1/4.2.6/sonar-scanner/bin/sonar-scanner' failed with exit code 3
I created a new organization-scoped token, and it still fails. As you can see from the logs, I don’t get a 404 error, so it should not be authentication-related. I believe this has happened before, but usually running the CI again fixes, not this time, though.
Hey @toba, you’ve resurrected a topic that’s 5 years old. Per the FAQ, please don’t do that. I’ve moved your post to a new thread, since it’s probably not relevant to the OP or not the same issue.
That being said, this problem is usually associated with the ADO PAT you have configured on SonarQube Cloud side. You said you already tried creating a new organization-scoped token, could you clarify if by this you meant a new SonarQube Cloud token or a new Azure PAT? What you should do it try creating a new PAT and configuring it on SonarQube Cloud’s organization binding settings.
I also would ask you to check a particular caveat that might be at play here: if this project was previously bound with a project-level PAT, that legacy project-level PAT may still take precedence over the organization-level PAT. Could you go to Administration > General Settings > Pull Requests and check for a warning saying “Legacy project-level PAT detected”?
Hi @andres, thanks for moving this to a new topic. I didn’t read through the FAQs.
Regarding the organization-scoped token, I created this within SonarQube Cloud and connected it via a service connection in ADO.
Thanks for the tip! There was an organization-level PAT that had expired. Found it in Organization → Administration → Organization settings → Organization binding → Personal Access Token.
I replaced the PAT, and it works now. Thank you!
I’m curious, though: why does SonarQube Cloud require 3 authentication methods to work with ADO:
Organization Binding
Organization PAT (what I just replaced)
Scoped Organization Tokens?
Is this standard? Or is my project just weirdly configured?
Hey @toba, I’m glad you got it to work! Regarding the authentication methods:
“Organization Binding” is not an authentication method in itself. Organization binding is mediated via the Azure PAT. So your 1. and 2. are the same. Organization binding + the Azure DevOps PAT stored in the binding config there lets SonarQube Cloud read Azure DevOps data and support PR integration/decoration.
The Scoped Organization Token is a SonarQube Cloud token. You configure it in the Azure DevOps service connection authenticates the pipeline runner to SonarQube Cloud so it can submit analysis. It does not grant SonarQube Cloud access back into Azure DevOps.
So basically:
Azure → SonarQube Cloud interactions are authenticated by a SonarQube Token (in your case a Scoped Organization Token, it could also be a user token).
SonarQube Cloud → Azure interactions are authenticated by an Azure token (a PAT).
While running PR analysis, the scanner in the CI pipeline makes a certain API call to SonarQube Cloud which triggers SonarQube Cloud to make an API call to the Azure project. This is why there’s a “SonarQube Cloud → Azure” interaction during the analysis.