Understanding Branch coverage reporting

SonarQube Cloud
1

Hi, I’m setting up SonarCloud for a Python project.

I have disabled Automated Analysis and configured New Code to be based on the “Previous version”

Since I’m testing the setup, I’m running SonarScannerCLI on the same branch and passing it different branch names to see how that affects results in the SonarCloud.

I ran this command to load code quality and coverage for Main Branch:

$ sonar-scanner -Dsonar.projectVersion=2.135.7 -X -Dsonar.branch.name=develop
...
15:23:57.398 INFO: Branch name: develop, type: long-lived
...
15:24:20.464 INFO: 403/403 source files have been analyzed
15:24:20.464 INFO: The Python analyzer was able to leverage cached data from previous analyses for 0 out of 403 files. These files were not parsed.
15:24:20.464 INFO: Sensor Python Sensor [python] (done) | time=16938ms
15:24:20.465 INFO: Sensor Cobertura Sensor for Python coverage [python]
15:24:20.466 DEBUG: Using pattern 'dist/coverage/python/coverage.xml' to find reports
15:24:22.566 INFO: Python test coverage
15:24:22.568 INFO: Parsing report '<anon>/dist/coverage/python/coverage.xml'
...
15:24:22.735 INFO: Sensor Cobertura Sensor for Python coverage [python] (done) | time=2270ms
15:24:22.735 INFO: Sensor PythonXUnitSensor [python]
...

The scan seems to go ok, coverage is detected and uploaded. Below is the screenshot of what I see in SonarCloud.

image
image1315×804 50.7 KB

I then make some dummy changes to the code (copy-paste some functions and rename them to fake uncovered sources), regenerate coverage metrics and rerun SonarScannerCLI making it appear as if it is running from feature branch:

$ sonar-scanner -Dsonar.projectVersion=2.135.7 -X -Dsonar.branch.name=feature/example
...
15:09:56.040 INFO: Branch name: feature/example, type: short-lived
...
15:10:19.894 INFO: 403/403 source files have been analyzed
15:10:19.894 INFO: The Python analyzer was able to leverage cached data from previous analyses for 0 out of 403 files. These files were not parsed.
15:10:19.894 INFO: Sensor Python Sensor [python] (done) | time=17313ms
15:10:19.895 INFO: Sensor Cobertura Sensor for Python coverage [python]
15:10:19.896 DEBUG: Using pattern 'dist/coverage/python/coverage.xml' to find reports
15:10:22.074 INFO: Python test coverage
15:10:22.076 INFO: Parsing report '<anon>/dist/coverage/python/coverage.xml'
...
15:10:22.271 DEBUG: Saving coverage measures for file <anon>'
15:10:22.271 INFO: Sensor Cobertura Sensor for Python coverage [python] (done) | time=2376ms
...

I then navigate to SonarCloud to browse coverage data for my feature branch and get the following:

image
image1328×765 36.5 KB

My questions are:

  1. Why coverage appears to have no data (horizontal line directly under “Coverage” label)?
  2. Based on the fact that feature branch says “67.3%” instead of “67.4%” on the main branch, I understand that coverage data has been processed. How can I drill down into it on a file basis?

Any help would be much appreciated.

2

Hey there.

Did you check your changes into Git? That’s required for SonarCloud to detect the changed lines in the short-lived branch, which right now it’s not.

3

I did not, no. Would keeping local commits suffice or do they also have to be pushed to remote?

4

Local commits are fine.

5

Ok, so I guess it’s not a matter of retrieving actual sources from the remote VCS but just using Git commit to differentiate between 2 scans, am I right? If so, is there a SonarScanner property I could use to set a dummy Git commit hash so that local runs are always treated as separate scans?

6

Just found sonar.scm.revision, going to try setting it to a custom value.

7

Nope, that didn’t seem to make any difference.

$ sonar-scanner -Dsonar.projectVersion=2.135.7 -X -Dsonar.branch.name=feature/INBCF-789_SonarCloud -Dsonar.scm.revision=foo1

That’s required for SonarCloud to detect the changed lines in the short-lived branch

I didn’t pay this part enough attention. Could you please expand on it a little bit?

Currently I can detect all modified files using git diff origin/develop and see all untracked using something like this:

git ls-files --others --exclude-standard -z | xargs -0 -n 1 git --no-pager diff /dev/null | less

which essentially is a combination of 2 git commands - one to list all untracked files and the other to generate their contents using patch-style output.

Are you saying that Sonar only supports diffs based on commit hashes?