What are you trying to achieve:
We want the SonarQube Cloud Code Quality block and PR decoration widgets to display analysis results directly in Bitbucket Cloud as they did perfectly before the mandatory Forge app migration.
What is the current behavior:
Today, September 15, 2026, we followed your official migration guide and upgraded the SonarQube Cloud app to the new Forge-based architecture. Immediately after the migration, the Bitbucket UI widget broke completely. It is now permanently stuck on “Not analyzed on SonarQube Cloud yet.”
What we have verified so far:
Our CI/CD pipeline runs flawlessly.
Scanner logs show successful execution and data upload (ANALYSIS SUCCESSFUL).
We can view the fresh, updated reports directly inside the SonarQube Cloud dashboard.
The issue is strictly visual within Bitbucket: the new Forge app’s frontend widget fails to fetch or map the metadata from SonarQube Cloud to the repository overview or PR screens.
We followed your official migration guide step-by-step, and it immediately broke an essential part of our daily workflow. We need SonarSource to investigate this migration failure and provide a working fix as soon as possible.
As you can see, everything is all good on the project’s source page.
However, this started appearing on all of our pull requests—including existing ones that were previously working. It happened immediately after migrating to SonarCloud Forge, and the migration itself completed without any errors.
Hey @Rodrigo_de_Moraes_Al and @Irineu_Ruiz, thanks for reporting this! This sounds similar to a known limitation that we are tracking internally: while the analysis is ongoing, the widget displays this message, and after the analysis is complete and has been processed by SonarQube Cloud, a browser refresh is needed for the widget to update.
Before I consider this as the same issue or before I loop the devs in, could you verify if in your case, the widget appears correctly after the analysis has finalized and the page has been refreshed? Please check if the PR has any ongoing analyses.
Hi Andrés, the issue seems to be different. After our update, even old open pull requests stopped displaying data, and new ones still aren’t showing Sonar data even after 24 hours—everything used to work perfectly before. On the other hand, the widget on the Source screen is displaying everything correctly after the update.
If you need any information we can provide to help, we are at your disposal. I checked the browser’s console and network tab on the Bitbucket PR screen, and there were no associated errors.
In Bitbucket, I also experience the issue with no analysis result on the Pull Requests page: “Not analyzed on SonarQube Cloud yet.” On the PR page in the linked SonarQube Cloud project the corresponding message is displayed: “No Pull Request analyzed yet”.
A week ago, In Bitbucket I upgraded the sonar app to the Forge Framework. I am unsure whether or not this affects the issue.
My findings:
In Bitbucket, on the Source page the sonar widget displays the expected results
The user has every Sonar project permission
The Bitbucket yml configuration file only includes a Default runner -i.e. no specific pull-requests runner. According to what I find in the documentation a specific PR-runner is not necessary Pipeline start conditions | Bitbucket Cloud | Atlassian Support
Hi Andres ,
I just want to check if there is any update to the issue from the team, and other limitations that should be aware of due to this migration. The official page does not mention this.
We have installed the forge app and the same thing happening on our PRs.
The repository source page shows main branch in SonarQube Cloud widget shows for the repository.
On PRs it shows “Not analyzed on SonarQube Cloud yet.”.
When I go to Project->Pull Requests on sonarcloud console it also says it “No Pull Requests analyzed yet” but it is weird because this PR has been analyzed before.
Do you have a pull-requests section in your bitbucket-pipelines.yml (pipeline definition)? Or do you only have a branches trigger only? You should have something like:
pipelines: # More info here: https://confluence.atlassian.com/bitbucket/configure-bitbucket-pipelines-yml-792298910.html
branches:
main:
- step: *build-test-sonarcloud
pull-requests:
'**':
- step: *build-test-sonarcloud
I have seen other users having the same issue because of a missing pull-requests trigger. It seems like in the old Bitbucket app, opening a PR would immediately show the widget populated from the source branch’s existing branch analysis: no pull-requests pipeline trigger and no PR-specific analysis required. Now it is necessary to actually run a PR analysis.
Hi Andrés, we don’t have a pull-request section in our YML, but we never had one and it has always worked. The documentation for migrating to the Forge app didn’t mention that this would be necessary. If it is going to be required from now on, please update the documentation so we can make the necessary changes in our projects.
The fix is deployed. It went to production on 28 September. Thanks for the reports and the detail, they made this quick to pin down.
What went wrong. The Bitbucket widget shows data for a pull request in two ways: from a pull request analysis, or, when there is none, from the analysis of the pull request’s source branch as a fallback. The migration to the Forge app dropped the second path, so any pull request without its own analysis showed “Not analyzed on SonarQube Cloud yet.” This is why repositories that never ran a pull request analysis worked before the migration and stopped after it. Nothing on your side caused it.
If you still see the old message, reload the pull request page. If it persists, check in Bitbucket workspace settings that the SonarQube Cloud app is up to date.
A recommendation, now that the widget works again. The branch fallback is a convenience, not a replacement for a real pull request analysis. If your bitbucket-pipelines.yml only has a branches: trigger, consider adding a pull-requests: one:
A real pull request analysis gives you things the fallback cannot:
Correct new code. A pull request analysis compares your changes against the target branch, so “new code” means the code in the pull request. A branch analysis uses the branch’s own new code period, which is not the same thing.
Code Insights in Bitbucket. Issues are annotated on the diff, and a report is attached to the pull request. You can then use that report in Bitbucket merge checks to stop a merge when the quality gate fails.
The Pull Requests section in SonarQube Cloud. The pull request appears in your project with its own issues, measures and quality gate, instead of only the branch.
Given the way we work, it doesn’t seem like a good idea to set up both branches and pull requests, because we follow an ‘always-branch’ approach—meaning for every Jira ticket, we create a branch off main.
If we configure both pipelines, every time we do the initial push to a branch, it triggers two pipelines in Bitbucket (which is what happened in my tests here): one for the branch and another for the pull request. Since Bitbucket charges per build minute, this would unnecessarily increase our costs.
However, the way you guys set it up now works perfectly for us.
