Broken SonarCloud links in Bitbucket Cloud PRs?

sonarcloud

(Jarosław Marek) #1
  • versions used: SonarCloud, Bitbucket Cloud, Sonar Maven plugin: org.sonarsource.scanner.maven/sonar-maven-plugin/3.4.0.905

  • error observed: The “See all issues on SonarCloud” link which appears in Bitbucket Cloud pull requests points to https://sonarcloud.io/project/issues?id=<project_key>&pullRequest=<branch_name>&resolved=false which results in “Component ‘<project_key>’ of pull request ‘<branch_name’ not found” error dialog and “The requested project does not exist.” error message on the page.

  • steps to reproduce:

  1. Configure SonarCloud <-> Bitbucket Cloud integration (https://sonarcloud.io/documentation/integrations/bitbucketcloud)
  2. Set “BitbucketCloud” under Administration->General Settings->Pull Requests->Provider in SonarCloud
  3. Run Sonar analysis on a branch which has some code quality issues
  4. Create a PR in BitbucketCloud from that branch
  5. Click the “See all issues on SonarCloud” link in the “Code Quality” section on the PR
  • potential workaround:
    Replace pullRequest in the URL with branch, since https://sonarcloud.io/project/issues?branch=<branch_name>&id=<project_key>&resolved=false seems to work just fine.

(Fabrice Bellingard) #2

Hi,

If you push another change on the PR (more precisely on the underlying branch), I’m pretty sure that once the analysis of that commit is done by SonarCloud, the link will be OK. Can you confirm my feeling?


(Jarosław Marek) #3

Hi Fabrice,
It doesn’t seem to be the case. Even on a PR with multiple commits added to it (and multiple subsequent Sonar analyses performed), I get the same error when I click on the “See all issues on SonarCloud” link.


(Fabrice Bellingard) #4

How do you run analyses? Do you rely on Bitbucket Pipelines or another CI?


(Jarosław Marek) #5

In the project I originally noted the issue in, we use Bamboo Cloud and rely on Sonar Maven plugin: org.sonarsource.scanner.maven/sonar-maven-plugin/3.4.0.905
Later I checked other projects and the issue seems to be affecting them as well. Other projects use Bitbucket Pipelines and the same Maven plugin for Java projects and Sonar Scanner 3.1.0 for JS projects.

Bamboo runs following command:
clean verify -U -P sonar -Dsonar.branch.name=${bamboo.planRepository.branchName}
Where sonar profile is configured to include additional plugins (sonar & jacoco) in the build. Please let me know if you’d like to see the relevant pom.xml snippets.

Bitbucket Pipelines config looks like this (for JS projects):

definitions:
  caches:
    # Custom cache definition for the sonar-scanner tool
    sonar: ~/.sonar/cache
...
- step:
        name: Analyze with Sonar
        caches:
          - sonar
        script:
          - sonar-scanner -Dsonar.branch.name=${BITBUCKET_BRANCH} -Dsonar.login=${SONAR_CLOUD_SECURITY_TOKEN}

For Java projects, bitbucket Pipelines config looks like this:

definitions:
  caches:
    # Custom cache definition for the sonar-scanner tool
    sonar: ~/.sonar/cache
...
 - step:
        name: Verify
        caches:
          - maven
          - sonar
        script:
          - mvn -B verify test -P sonar -Dsonar.branch.name=${BITBUCKET_BRANCH}

(Julien Henry) #6

Hi,

sonar.branch.name should be used to analyze branches. To analyze a pullrequest, the parameters are different. See https://sonarcloud.io/documentation/pull_request.

On Bitbucket pipeline, the configuration should be automatically done, so simply remove the sonar.branch.name parameter. Pipelines are only triggered when you push in a branch (not when you create a PR). There is an open ticket on Atlassian side.

For your build on Bamboo, we have currently no integration, so you’ll have to script the build to pass the correct parameters, depending on if you want to analyze a branch or a PR.

Still the link is misleading, I have created a ticket to see if we can detect when there is actually an analysis or not of the PR:
https://jira.sonarsource.com/browse/SONAR-10977


(Jarosław Marek) #7

Thank you Julien. I didn’t think that analysing branches is so much different than analysing a PR. I guess I was just thinking about the basic case when a feature branch is being merged to the default long lived branch.

I’ll follow your recommendation and will make sure that next time I do check the docs before raising issues :wink: but yeah, existence of that link was a bit misleading in this case.