PR analysis shows 0 new code lines

SonarQube Server / Community Build
, , ,
1

Hello everyone,

Thank you in advance for your time and assistance!

We are currently using a CI-Pipeline that involves GitHub, Jenkins, and SonarQube for a Java-Maven project. Unfortunately, we have been encountering an issue where the new source code, introduced as part of a Pull Request (PR), is not being scanned properly by SonarQube. However, SonarQube successfully scans source code for non-PR branches.

Below, I will provide more information regarding our deployment and the issue at hand:

  • SonarQube: Developer Edition, Version 10.0 (build 68432).
  • Jenkins: Version 2.401.2, Pipeline Multibranch: 756.v891d88f2cd46
  • GitHub: Public Instance (github.com)

Our SonarQube is installed via the zip file.

Our objective is to ensure that the Java source code introduced by a PR is properly scanned by SonarQube.

Here’s a description of the problem:

Currently, a PR report in SonarQube always indicates that 0 lines of code have been scanned.

image
image1402×217 12.6 KB

The relevant stage in our Jenkins Multibranch-Pipeline looks like this:

image
image1801×665 52.9 KB

Our overall system architecture looks like this:

sequence.drawio
sequence.drawio541×562 15.7 KB

From the Jenkins build logs I can see that sonar-scanner is invoked and the JavaSensor does run:

[2023-06-06T06:33:35.584Z] [INFO] 08:33:35.504 SonarQube version: 10.0.0.68432
...
[2023-06-06T06:33:42.121Z] [DEBUG] 08:33:42.091 '<redacted>/GtFunctionState.java' indexed with language 'java'
...
[2023-06-06T06:33:54.733Z] [DEBUG] 08:33:54.565 '<redacted>/GtFunctionState.java' generated metadata with charset 'UTF-8'
[2023-06-06T06:33:54.733Z] [INFO] 08:33:54.566 Server-side caching is enabled. The Java analyzer was able to leverage cached data from previous analyses for 743 out of 839 files. These files will not be parsed.
[2023-06-06T06:33:54.733Z] [INFO] 08:33:54.566 Using ECJ batch to parse 96 Main java source files with batch size 262 KB.
[2023-06-06T06:33:54.733Z] [INFO] 08:33:54.568 Starting batch processing.
[2023-06-06T06:33:54.983Z] [DEBUG] 08:33:54.874 [SE] Loaded 227 hardcoded method behaviors.
[2023-06-06T06:33:57.467Z] [INFO] 08:33:57.149 100% analyzed
[2023-06-06T06:33:57.467Z] [INFO] 08:33:57.149 Batch processing: Done.
[2023-06-06T06:33:57.467Z] [INFO] 08:33:57.150 Optimized analysis for 85 of 96 files.
[2023-06-06T06:33:57.467Z] [INFO] 08:33:57.205 No "Test" source files to scan.
[2023-06-06T06:33:57.467Z] [INFO] 08:33:57.205 No "Generated" source files to scan.
[2023-06-06T06:33:57.467Z] [INFO] 08:33:57.206 Sensor JavaSensor [java] (done) | time=3642ms
....

We have tried the following already:

  • Removed SONAR_PULLREQUEST_{KEY|SOURCE|Target} from mvn command (did not work)
  • Stripped down project to bare essentials & compiled anew (did not work)
  • Set up new instances of SonarQube + Jenkins and configured everything from scratch (did not work)

Scanning new source code introduced as part of a PR generally seems to work as we also have projects hosted on GitLab using gitlab-ci to invode sonar-scanner. The combination of using Jenkins and GitHub seems to introduce the issue described above.

Any assistance or guidance to help resolve this issue would be immensely appreciated. Also, kindly inform me if there are any related tickets or discussions that might help in resolving this issue.

I am also wondering whether this is related to:
github issue

Thank you for your time and consideration.

2

Hey there.

Just to make sure everything is clear, you expect that GitFunctionState.java has lines that have changed in this pull request, correct?

There should be some relevant log messages about the detection of changed files / lines

Such as…

INFO: SCM collecting changed files in the branch (done) | time=216ms
DEBUG: SCM reported 0 files changed in the branch
WARN: File '/opt/workDir/*component.ts' was detected as changed but without having changed lines

Can you share any relevant log snippets about changed files or changed lines (good keywords to search in your logs). Or any WARN statements.

3

Hi Colin,

thank you for your swift response.

Indeed, you’ve captured the essence of my issue. I anticipate that GitFunctionState.java should reveal lines that have been modified in this particular pull request.

Here are the pertinent log messages related to SonarQube/SonarScanner:

[2023-06-06T06:33:35.584Z] [INFO] SonarQube version: 10.0.0.68432
...
[2023-06-06T06:33:38.584Z] [INFO] Pull request 2461 for merge into testing from DEV-85
[2023-06-06T06:33:35.584Z] [WARNING]  The property 'sonar.login' is deprecated and will be removed in the future. Please use the 'sonar.token' property instead when passing a token.
[2023-06-06T06:33:35.584Z] [INFO]  Load project repositories
[2023-06-06T06:33:35.584Z] [DEBUG] GET 200 https://<redacted_sonarqube_url>/batch/project.protobuf?key=<redacted_project_key>&branch=testing | time=15ms
[2023-06-06T06:33:35.584Z] [INFO] Load project repositories (done) | time=26ms
[2023-06-06T06:33:35.972Z] [INFO] SCM collecting changed files in the branch
[2023-06-06T06:33:35.972Z] [INFO] Merge base sha1: 114426b4020380e35a90c47321636b1b07f02746
[2023-06-06T06:33:35.972Z] [INFO]  SCM collecting changed files in the branch (done) | time=71ms
[2023-06-06T06:33:35.972Z] [DEBUG] SCM reported 0 files changed in the branch

I’ve confirmed that changes were indeed made to the files, although this is not mirrored in the log. I’ve also ascertained the presence of git blame information.

No other warnings concerning SonarQube seem to be present in the log. We do have a handful of compiler warnings, but nothing that appears to relate to SonarQube, SonarScanner, or Git/SCM.

I appreciate your assistance in this matter.

4

First, a very basic question:

You confirm that this statement is correctly about PR 2461? That DEV-85 is the PR branch and testing is the target branch?

The scanner should normally be able to automatically detect that it’s in a PR context assuming that CHANGE_BRANCH, CHANGE_ID and CHANGE_TARGET environment variables are available. This can be less error-prone than trying to configure it yourself. You might consider removing this configuration.

What can you tell me about this commit? Is it indeed the forkpoint between testing and DEV-85?