Recently, we encountered an issue where SonarCloud ceased to display reports on our GitHub pull requests. Although we successfully publish reports to SonarCloud dashboard, but the status checks are not being updated on our PRs check & decore are not added on PR. We attempted to resolve this by reinstalling the SonarCloud GitHub app on our GitHub organization, but the reports still fail to appear on our pull requests. We seek assistance with this problem. Our continuous integration scans are conducted on Azure DevOps and GCP Cloud Build.
Yes we already binded our sonarcloud to project & verified same , the report are getting published to the Sonar project also , but only issue is that the sonarcloud enable to add decore /check/comment to PR
It looks like SonarCloud is unable to locate the GitHub application that should be installed on your SonarCloud organization.
Can you (or an organization admin) verify that the SonarCloud GitHub application is installed and has access to this repository? You should be able to check that first part in your organization level Administration > Organization settings > Bind this organization to GitHub
I have checked it seems correctly configured & sonar cloud application is installed on GitHub & provided with correct access. & binded with the correct GitHub org on sonarcloud , just want to more context m recently we have migrated to new GitHub org & rebinded the new org & also uninstalled the sonar app from github & reinstalled again on New github org & rebind the sonar with new github org:
We worked on that with @TomVanBraband today, and from what we can see in our logs, it looks like you recently renamed your GitHub organization. Do you confirm?
Looking deeper into it, we realized that, while this is well handled for public repositories, it doesn’t work for private ones. Do you also confirm that you are working with a private repo here?
Please let me know so we can see what are the next steps.
Thank you for your confirmation. We looked into this internally and understood what the problem is.
We don’t support Organization renaming. We should update repository slugs in our database when it happens, but we don’t
Thankfully GitHub helps us a bit and handles redirects in this case, but only for public projects.
Our UI showing the project bindings (Administration / General Settings / Repository bindings) has a flaw because it shows the project correctly bound even though the repository doesn’t exist on GitHub (we have the old reference, which doesn’t exist anymore)
There are multiple things we will improve here, but I’ll put those details later. Let’s first focus on fixing the issue on your side. I’ve tried this and the easiest is to:
Go to Administration / General Settings / Repository bindings on the faulty project
Select another repo, whichever
Save
Select the right repo again
Save
This will essentially update the reference of the repo we have in the database, and PR decoration will work again. Could you try and let me know if that solves the issue?
Of course, if you have a lot of repos that would be tedious. There is a way to automate this using our API, let me know first if you can manage this way or not.
Thank you for confirming that you could successfully resolve the situation.
This is just to let you know that after discussing internally, we created the following tickets for improving such situation of an organization being renamed, or even more broadly of a repository being renamed:
First, we will simply hook to the GitHub Organization rename event to rename all repository references we have on SonarCloud. Today this is a webhook we receive but don’t act upon.
Secondly, we will fix our UI of Administration > General Settings > Repository binding so that it doesn’t show a valid binding if the repository does not exist (This is to make the problem explicit for organizations that have been renamed already and are in the same situation that you are, or if a repository had been renamed)
Finally, as any GitHub repository has a unique and stable ID (vs. its slug that can change), we will explore a solution to fallback on using this unique ID in case we can’t find the repository through its slug. This would cover any use case where somehow the repository slug we have is wrong
These improvements will be implemented in the next months (no specific ETA though).
Thanks for your reports!!
, As you suggested on sonar cloud project level we made the change