Although it’s working, the link is WRONG. Before the “View more details in SonarCloud” goes to the PR branch dashboard metrics, not the “master/develop” or long live branch.
Other link works as before it goes to master/develop which I think also should be corrected. All links should always go to the PR branch. We were able to live about this before cause there is one link that is working fine, now there is no link that is correct.
for me it goes right to the pull request analysis in sonar. Do you set the pull request key etc when you do a sonar scan -Dsonar.pullrequest.key? I used the short lived branch scan for over a year and i also had this issue sometimes i am not sure if its related to short branches analysis only. But since the original issue happened i switched to pull request analysis so we get a nicely decorated pull request.
Oh I haven’t tried that. Let me check on my dev machine first. Our CI generation of the parameters is controlled by the script by DevOps on Jenkins.
I checked that we are passing sonar.branch.name in the Jenkins instead. Should that be enough for SonarCloud to associate? It was able to do before with “View more details in SonarCloud”. The link to the analysis actually match the PR branch name.
I also checked that sonar.branch.name and sonar.pullrequest.key cannot be both specified.
It should be enough i used short lived branch analyses for over a year. Yeah if you use sonar.pullrequest.key you also need some other params like the branch name and base branch etc. You can no longer use sonar.branch.name but i would think that the link always has to work even for short lived branch analysis.
I moved this to a new topic since it seems to be a different issue and I’ll investigate what’s going on tomorrow. In the mean time if you have public projects with this issues don’t hesitate to share a link.
But you are right, if you are on the PR widget, those links (all of them) should go to the matching branch on SonarCloud. And it should work both if you configured with short-lived branches or pull requests.
Hello @Francis_Marasigan,
Thanks for reporting this, as @Gregoire_Aubert said we will be fixing this.
However I want to explain the difference between using sonar.branch.name and the sonar.pullrequest.* parameters (sonar.pullrequest.key, sonar.pullrequest.branch and sonar.pullrequest.base).
sonar.branch.name will launch a Short-Living Branch analysis. If you do not specify the sonar.branch.target parameter, SonarCloud will assume that the short-living branch should be analyzed against the default branch. If you are actually analyzing a PR between two branches, and neither of them are the default branch, this will give you wrong results.sonar.pullrequest.* properties and if your organization and projects are bound to your Bitbucket team and repositories you will be able to benefit from Code Insight reports. This is because we need the link to the repository and the PR to be able to send the Code Insight report to Bitbucket Cloud.For most CI providers we set-up the sonar.pullrequest.* configuration automatically, but since you are using Jenkins, you will have to set-up the parameters yourself though.
@Francis_Marasigan Could you share the payload that your have in the branchesAndPrs object of the code_quality api call for a PR where you have the issue with the links ?
Yes, that is correct we don’t pass the branch.target since all our PR target branch is our main branch “master” or “develop” depends on the project.
Still asking our DevOps if we can switch our CI pipeline to start using sonar.pullrequest.*
@Gregoire_Aubert Not sure if this is what you are asking
dotnet sonarscanner begin /k:***_checkout.checkoutgateway /o:**** /d:sonar.login=****** /d:sonar.branch.name=feature/CHECK-9010-improved-code-coverage-of-che /d:sonar.scanner.force-deprecated-java-version=true /d:sonar.host.url=https://sonarcloud.io /d:sonar.cs.opencover.reportsPaths=./**/coverage.opencover.xml /d:sonar.coverage.exclusions=[*.IntegrationTests.*]*,[*UnitTests*]*,*Startup*,*Program*,[*]*Repository,[*]*Entity,[*MetricsService*]*
Sorry my request wasn’t very clear.
I meant the payload that your browser receives to populate the PR widget when you are visiting the pull request page on Bitbucket Cloud.
You can retrieve it thanks to the developer console of your browser, like this (using the “sonarcloud” keyword to filter the requests should help):
It should help to investigate and reproduce if you can send me the json payload that you get in the response tab (don’t hesitate to replace any sensitive data that you could have in there like your project or organization key).
Thanks for the help @Francis_Marasigan! Thanks to your snippet of code we identified the issue and we are gonna deploy a fix this week.
We deployed a fix today and the links should be correct from now on.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
