SonarCloud PR Analysis/Decoration on BitBucket Cloud not working

SonarQube Cloud
, ,
1

Private BitBucket Cloud repo for Android project.
Analysis ran in BitBucket Cloud Pipeline.

I am having an issue with the SonarCloud PR Analysis, which in turn seems to be affecting the SonarCloud PR Decoration.

It seems like SonarCloud is not able to see any other branches than the ‘main’ branch of the Repo.
Only merges into ‘main’ branch gets analysed and tracked in SonarCloud.
PRs into ‘main’ or any other branches run the BitBucket Pipeline, that runs SonarCloud Gradle task, but no info is made available in either SonarCloud portal or BitBucket PRs.
The SonarCloud section of the PR, ‘Code Quality’ only displays the text “Not analyzed on SonarCloud yet”.

Below is the bitbucket-pipelines.yml file that runs the analysis.

image: bitriseio/docker-android

clone:
  depth: full              # SonarCloud scanner needs the full history to assign issues properly

definitions:
  caches:
    sonar: ~/.sonar/cache  # Caching SonarCloud artifacts will speed up your build
  steps:
    - step: &build-test-sonarcloud
        name: Build, test and analyze on SonarCloud
        caches:
          - gradle
          - sonar
        script:
          - sudo update-alternatives --set javac /usr/lib/jvm/java-11-openjdk-amd64/bin/javac
          - sudo update-alternatives --set java /usr/lib/jvm/java-11-openjdk-amd64/bin/java
          - export JAVA_HOME='/usr/lib/jvm/java-11-openjdk-amd64'
          - ./gradlew build sonarqube -x lint
        artifacts:
          - build/libs/**

pipelines:                 # More info here: https://confluence.atlassian.com/bitbucket/configure-bitbucket-pipelines-yml-792298910.html
  branches:
    master:
      - step: *build-test-sonarcloud
  pull-requests:
    '**':
      - step: *build-test-sonarcloud
4

Welcome to the community, and sorry for the delayed answer.

When your build pipeline is executed on a pull request, does the gradle command (which executes the code analysis) complete successfully? Can you confirm in the log output of the pipeline run? If you add --info to the gradle command, then the end of the output should look something like this:

ANALYSIS SUCCESSFUL, you can find the results at: https://sonarcloud.io/dashboard?id=foo&pullRequest=123
Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
More about the report processing at https://sonarcloud.io/api/ce/task?id=bar

Notice the &pullRequest= at the end of the first link, this is a good sign of a correctly configured pull request analysis.

If the main branch is correctly analyzed, I see no reason for the pull request analysis to not work, however, your description suggests that the pull request analyses in fact have not reached SonarCloud. The scanner output (of the gradle command) should help us understand what happened.

5

Hi

Thank you for the response, delayed or otherwise.
The suggestion of looking at the --info printout was actually very helpful.

For one thing, it did show me that BitBucket Pipelines has a limit to how much logging it will show before cutting off the remainder.
Secondly, the point about looking for the final URL in the ANALYSIS SUCCESSFUL line does reveal that every build is simply being considered as the standalone analysis and not a PR analysis as the URL does not have a &pullRequest=.
It only contains the https://sonarcloud.io/dashboard?id=foo portion, which would indicate that there is some issue in regards to determining that the analysis is for a PR.

I have tested this on two different CI environments, one BitBucket and one BitRise.
However they both relay on a BitRise Docker image, but I don’t see how that would impact the analysis.

Is there any docs or guides on how to deal with this? Any flags, environment settings or options that can used?

PS: I see that the analysis reaches the SonarCloud as the timestamp for the last time an analysis was run updates, matching build pipeline execution.

1 Like
6

Once again, sorry for the delay. :sweat_smile:
I appreciate your patience, and if you pinged me for an update sooner, that would have been totally fair.

Here’s how it works. Pull request analysis requires several parameters: the identifier of the pull request, the branch that it wants to merge into, and for best experience, a couple of other metadata, such as the HEAD commit sha1. To remove the burden from users of all this setup, and also the logic to perform a main branch analysis or a pull request analysis, we have a detection mechanism, based on environment variables. (I think this is not documented, I signaled to our documentation team to see if we can improve something here.)

For analyses on Bitbucket Cloud, the following environment variables are expected to auto-configure as a pull request analysis:

  • CI=true
  • BITBUCKET_PR_ID non-empty
  • BITBUCKET_REPO_OWNER_UUID non-empty
  • BITBUCKET_REPO_UUID non-empty
  • BITBUCKET_BRANCH non-empty
  • BITBUCKET_COMMIT non-empty
  • BITBUCKET_PR_DESTINATION_BRANCH

It would seem that these variables are not visible to the scanner process executed in its container. If you make sure these variables are present and correct, then it should work.

For analyses executed on BitRise, we don’t have such auto-configuration yet. We already have a feature request logged for that, you can track that on SCCOMM-45.

8

We decided to not proceed with this feature request (SCCOMM-45). Thanks for your understanding.

9

I use Jenkins as CI with bitbucket push pull plugin being used to handle webhooks from bitbucket.
This is how the flow looks:

  1. Creating/updating a PR in bitbucket sends a webhook event with a payload
  2. Jenkins job listens to these events and triggers the build job
  3. The build job has ‘mvn verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.projectKey=foo’ command.
  4. Printed the environment variables and ensured that all the above environment variables are set.

I still am unsuccessful in making the PR analysis to work. Is there anything else that I may be missing?