We transferred a repo to another org and then forked it back. Now scans don’t connect to the correct repo
Potential workaround
Delete and recreate the SonarCloud project
I recognize that this is 1000% an edge case, but is there any way to adjust the ALM URL so that it points to our new forked repo or is deleting/recreating the SonarCloud project the advisable route?
Just to make sure I understand – can you describe the behavior a little more? If scans aren’t connecting to the right repo… what is happening (or how can you tell)?
Thanks for your reply! Let’s call the organizations org-A and org-B. We transferred a GitHub repository from org-A to org-B and then created a new fork of the repository back in org-A. It seems SonarCloud references followed the repo to org-B (which I suppose makes sense since the repo was transferred), but we wanted to keep scanning the repo in org-A.
Unfortunately the SonarCloud project has since been deleted and recreated, so I can’t point you to the old project directly, but when we opened a PR, the GitHub link in the SonarCloud project redirected to org-B and SonarCloud was using PR references (i.e the destination branch and source branch) from org-B instead of org-A, so it wasn’t able to scan properly.
I hope that makes sense–let me know if anything there isn’t clear!
If it helps I do have logs from this PR #7, which was a test to introduce a vulnerability and should fail the Quality Gate:
The old project where it was pointing to org-B: SonarCloud logs
The new project after we delete/recreated it and it was pointing to org-A: SonarCloud logs
Sorry for the long wait.
Thank you for the input it is an interesting use case that you have described.
SonarCloud supports organisation migration but does not support moving projects between organisations.
As for now, we do not have the item in our product roadmap we cannot promise that the feature will be delivered.
