I tried switching to the .us URL, but that gives a different error.
Failed to query service connection API: 'https://sonarqube.us/api/organizations/search?member=true'. Status Code: 'Unauthorized', Response from server: ''
I think I found the remaining Bitbucket binding in General Settings → Pull Requests. I don’t see an option for GitHub in the Provider dropdown, so I just cleared it (removing Bitbucket). I’m testing now.
For each of our 4 projects **Administration > General Settings > Repository binding **, shows “GitHub repository binding” and the “Current binding” repository is correct. Save is disabled unless I change it to an incorrect repository.
For each of our 4 projects **Administration > General Settings > Pull Requests **, Provider is empty. There isn’t a GitHub option on this list. Should there be?
As an experiment, I changed the Repository binding for a single project to an incorrect one, hit Save, then changed it back. I started a new build and now it looks like SonarCloudAnalyze is working for all projects. I don’t know if someone fixed it on the backend or if my Save and re-Save flushed out some bad settings.
I jumped the gun saying this is working. What I’m seeing now is:
I create a PR in GitHub. This triggers the Pipeline in ADO. This build fails.
From ADO, if I open the pipeline run and click Run new, and run it with all of the same parameters, then it works. I have no idea why that would be.
It will sound weird, but it’s best just to leave sonar.pullrequest.provider as null. This is some old, legacy config that we plan to remove. I think it’s just useless, but it might actively be harmful if you try and configure it.
Would you be able to provide DEBUG level logs from both runs (add sonar.verbose=true). Happy to open a private message if that’s easier for you to share them that way.
Colin,
Any progress? I wonder if I need to recreate the projects? I don’t suppose there’s an easy way to do that and carry over the settings, is there?
I can see in the logs that you shared that the successful analysis is a branch analysis that doesn’t result in a call in to your DevOps platform, but the failed one is a pull request analysis that does try to look up the PR. It tries to look up that PR in Bitbucket instead of GitHub, which of course doesn’t make sense if your project is now bound to GitHub.
I’ve collected all these details to share with our team, who can hopefully figure out what hasn’t been updated. While this process of rebinding an org is somewhat an unofficial workaround… it’s a workaround we document internally.
It would be interesting to know if deleting/recreating the project fixes the issue, but I don’t want you to muck up your project history!
The issue here is that when you moved from BitBucket to GitHub, we didn’t properly clean up the project bindings. Since your repositories stayed the same, the binding looks correct, but it is still marked as a BitBucket binding internally.
Unfortunately the product currently doesn’t support this scenario well, we’ll fix this internally. In the meantime, the only option is unfortunately to recreate the projects.
Apologies for the inconvenience.