Page Comparison

Configuration Checklist

1. Verify your SonarQube™ server settings in global settings of Bitbucket

2. Run SonarQube™ source code analysis for main branch

   1. Configure the source code analysis

   2. Analysis results must be visible in SonarQube™

3. Configure corresponding SonarQube™ project in repo settings of Bitbucket

4. Go to source code view and see the existing issues/stats

   1. You should see the SonarQube™ statistics and issue annotation

      

   2. Statistics and annotations are missing? Verify your Bitbucket repository configuration:

      1. Did you configure the correct analysis directory?
         

      2. Does the SonarQube™ project key match with the configuration in Bitbucket?
         

         

5. Create a pull request with issues in the code.

6. Run SonarQube™ source code analysis for source branch of your pull request.

7. Go to the pull request view and check if the analysis results are visible. You should see a quality gate status overview, and issue annotations in the pull request diff.

   1. An error

      

      hints at a wrong analysis configuration or a wrong analysis directory setting

   2. No issue annotations:

      1. Verify that you can see the issues that should be shown in SonarQube™

      2. Do the issue annotations appear after clicking “Refreshing Sonar™ analysis” in the pull request overview? Then check your Webhook configuration

...

c) For MySQL/MariaDB users: check that you use UTF-8 character set instead of latin1 or similar, otherwise you will not see annotations in your pull request and DataTruncationException in your Bitbucket server log.
To fix this, change the DB character set for the Bitbucket database tables to UTF-8 as described in the linked Atlassian ticket.

d) Check the SonarQube™ project mappings under the repository settings of the app. If the project mappings use an invalid module or analysis directory, the pull requests cannot get annotated correctly.

e) For older SonarQube™ versions, make sure to pass -Dsonar.analysis.scmRevision=COMMIT_ID with the commit SHA from your CI system to your analysis invocation.

4. Receiving the error message of “The ‘component’ parameter is missing”.

...

• you are using localhost or a wildcard address for Bitbucket which is not supported because SonarQube™ does not allow these. Please use the real Bitbucket hostname instead.

• you do not have a valid HTTPS certificate for Bitbucket configured in SonarQube™'s JVM, see this community article for more information.

• you have invalid proxy settings that prevent SonarQube™ from connecting Bitbucket: check your -Dhttp.proxyHost and -Dhttp.nonProxyHosts JVM arguments

• SonarQube™ can only reach Bitbucket on a different DNS entry (e.g. VPN) than the configured base URL in Bitbucket → Use manual webhook setupwith the domain that can reach Bitbucket.

...

See Unable to start the plugin container / OSGi cache corruption in Bitbucket

8. SSL certificate error: "PKIX path building failed"

Possible Causes:

• SSL certificate for SonarQube™ is not in JVM of Bitbucket

• JVM versions < 1.8.0_151 not properly recognizing the certificate authority

• Using a self-signed certificate: Java does not trust the certificate and fails to connect to the application. You have to add that certificate to the trust store.

For more information, follow the advice on https://confluence.atlassian.com/kb/unable-to-connect-to-ssl-services-due-to-pkix-path-building-failed-779355358.html

9. Warning: No active SonarQube™ projects

If you get the warning No active SonarQube projects in your pull requests, then this is most likely due to the fact that none of the configured SonarQube™ projects in your repository settings match the file paths in the diff of the pull request.

To fix this:

1. Go to Repository settings → Sonar

2. Check your configured projects under SonarQube Projects: the files in your pull request have to start with one of the configured module directory paths of your projects.
   Example:
   if your pull request touches files under src/main/java/com/mycompany/ui, make sure you either have
   a) an empty module directory (if you have just one SonarQube™ project in a repository).
   b) a SonarQube™ project with module directory src/main/java that maps to the SonarQube™ project for that analysis directory (multiple SonarQube™ projects in repository) .
   
   The app shows issues & statistics of any SonarQube™ project that has a matching module directory. Note that an empty module directory always matches any path, so if you only have a single SonarQube™ project in your repository, just use an empty empty module directory .

3. Add a SonarQube™ project or fix the existing ones.

4. Go back to your pull request, and you should not get this warning anymore, but instead see the SonarQube™ statistics for the configured project(s).