CI system used - Azure DevOps (YAML tasks SonarCloudPrepare@3, etc.)
Scanner command used - dotnet & cli
Languages of the repository - C# & JS/TS
Steps to reproduce - Create a new GitHub PR
Error observed:
ERROR: Error during SonarScanner execution
ERROR: Could not find the pullrequest with key '2190'
ERROR: Caused by: Error 404 on https://sonarqube.us/api/alm_integration/show_pullrequest?project=[projectName]&pullrequestKey=2190 : {"errors":[{"msg":"You don\u0027t have permission, or the provided pullrequest with key \u00272190\u0027 doesn\u0027t exist."}]}
We recently migrated repos, branches and PRs from Azure DevOps to GitHub. Afterwards, we started getting the error message above, but only sometimes. Based on my research through other topics (referenced below), it seems I need to change our SonarQube Cloud Organization binding. This was not done as part of the migrationâtesting completed successfullyâand so our SonarQube Cloud org is still bound to Azure DevOps.
My primary question is this: is the current âchange organization bindingâ feature supported from Azure DevOps? A topic quote from October 2025, seems to indicate it is not:
âŚsuch as moving away from platforms like GitHub or Bitbucket to another serviceânot from Azure DevOpsâŚ
If it is supported, I could use some additional guidance, because I get the following message when I attempt to login using my GitHub account (I am a system admin using my AzureDevOps account).
SonarQube Cloud does not support linking an organization to more than one DevOps platform at a time.
Your email address is already linked with this user account:
Clicking on âContinueâ will link this email to another user account:
î˘
Information:
This means the following:
Your email address will be removed from the first account.
Your data will not be erased but you will no longer receive email notifications from this account or have issues automatically assigned to it.
Weâll send notifications and new issue updates from your second account instead.
I can certainly manually rebind all projects, but there is a lot of work in flight, so I want to make sure I am headed the proper direction before making pervasive changes.
Welcome to the community and thanks for this report!
Many systems will return a 404 error (i.e. what youâve asked for doesnât exist) rather than a 403 error, thus admitting that the resource exists but you just donât have access to it.
You should double-check the PAT youâve configured SonarQube Cloud with.
Thanks for the feedback! I did read this in other topics and can confirm my PAT is valid. I should have mentioned this in the original post, but some PRs work just fine, which makes me think it is a symptom of migrating code and PRs from AzDO to GitHub. Only after that date did we see this issue.
Do you happen to know if changing the organization binding is supported going FROM AzDO to GitHub?
I should have been more specific. There are two places in SonarQube Cloud that you can configure a PAT. At the organization level and at the project level. The project-level one kicks in for PRs in some places. The fact that youâre not seeing this uniformly across projects makes me even more willing to bet that this is a problem with the PAT - configured at project level. Can you check that, please?
Ah, makes sense. I should also clarify that we have a mix of bound and unbound projects, but none of them have PATs configured at the project level. Rather, that PAT only exists for the organization, and the Organization Settings UI says it is valid.
That formatting looks specific to something in AzureDevOps. The human-friendly version is listed above and also in another part of that same message. Yes, that PR and branch were created after the migration from AzDO to GitHub.
Thank you for following up!
I plan to add a GitHub PAT to the project in question today and see if that changes the behavior. Any other ideas I can try?
So the actual PR number is 2190. That helps me decode this:
To this: '2190'
So the question is where those apostrophes are coming from. Are you manually specifying the PR analysis parameters, or letting the system pick them up automatically from the environment?
Given the AzDO logs for the SonarQube prepare task, I suspect the Sonar scanner is attempting to pull the PR details from AzureDevOps, but it does not exist because those were migrated to GitHub.
So then the unicode formatting (\u0027) is simply internal to the AzDO platform. It appears to encode the âââ character to unicode, perhaps because the log statement is included in double quotes (â).
Since youâre letting the system auto-configure the PR properties, the values are coming out of the environment. Can you stick some echoes in your pipeline to see what the raw SCM metadata looks like? Iâm not sure what variable names weâre looking for, so itâll probably just be easiest to dump the entire env* and be choosy about what you post here.
Ann
* I feel obliged to point out that if there are sensitive values in your env, this will dump them into your logs, which could be ticklish, security-wise.
Attached are the ENVs, with irrelevant ones redacted. Also, I did confirm with a new PR SonarScanner is pulling data from AzDO, because the because the PR branch it found (in the logs) is from AzDO and not GitHub.
AzDO:
ENVs (attached)
Itâs difficult to tell in the file, but one of the variables we want is System_PullRequest_PullRequestNumber which has a value of 2195.
So⌠weâve got 2195 in the environment, no-quotesâŚ
Now Iâm down to straw-grasping. You migrated from ADO to GH for the SCM, but youâre still using ADO as your CI. Is there an option in ADO to turn off the quoting?
Is there anything in particular you had to do to make ADO check out from GH that might be interfering?
While youâre pondering that, Iâm going to go ahead & flag this for folks who might have a deeper insight.
Thanks for the update, Ann. Can you tell me the SCM you have in the SonarQube system for PR 2195? In this case, the same PR exists in AzDO, but Iâm currently using a PR from GitHub; I suspect this is why this scan works where others do not. I confirmed that pattern with recent failing scans; the PRs that fail do not exist in AzDO where as the ones as do work fine.
I will look, but I am do not think I can control the formatting for quotes in AzDO.
Iâm not clear on the second question, but after your insight and my data, I suspect the primary issue is the the SonarScanner is not pulling data from GH; rather only AzDO which is how the SonarQube project is bound.
Thanks for escalating this topic and I can certainly setup a short call to show more or do some live troubleshooting.
You would have better insight into this than I do - if we stored that information as such. Which we donât.
It sounds like maybe youâre not as migrated as you think you are.
When you said you had migrated, I didnât think much about it. But we donât actually support changing the binding of an organization away from ADO. And I think thatâs the root of the problem here.
The PR is failing because itâs truly 404 in what SonarQube Cloud thinks is the system of record: ADO. And at this point Iâm afraid I only have bad news for you: you need to create a brand new organization from GitHub and start over with all your projects.
All of our testing worked fine which is why we thought the migration was complete. Itâs only now with increased usage that we see this error. Kudos to SonarQube, everything else still works just fine, albeit probably not ideal since the data doesnât line up in GH.
Is there any guidance for custom automation that can help us migrating existing projects and configuration from one org to another? For example, last year, we migrated everything from SQ Server to SQ Cloud using custom automation; 0 downtime. But I would like to use and reference any formal guidance if it is available.
OK, no worries. I built the script and will test it today. My primary questionâwhich I hope is an easy questionâregards updating my identity from AzDO to GitHub. When I log into SonarQube Cloud using my GitHub, a page warns me that my existing identity will be updated because it shares the same email address with my AzDO provider.
Can I continually âswitchâ that identity between AzDO and GitHub in the SonarQube Cloud platform? I need to build and configure the new org bound to GitHub and then switch back to AzDO for reference and to validate the script I built.
All of our testing worked fine which is why we thought the migration was complete. Itâs only now with increased usage that we see this error. Kudos to SonarQube, everything else still works just fine, albeit probably not ideal since the data doesnât line up in GH.
