When changing some lines only in a short-lived branch, the whole files considered to be “new code” and the test code coverage is calculated taking the whole file into account so it is lower than expected.
On the other hand the other rules are not applied to the whole file so no code smells are shown for unchanged code in the rest of the file.
I found a similar issue regarding code duplication:
This is the actual diff to the target branch as shown in Bitbucket:
This is what SonarQube shows (rest of the file looks the same):
Here is what i found relevant in the logs:
10:03:33.022 DEBUG: Sensors :
10:03:33.024 INFO: SCM provider for this project is: git
10:03:33.024 INFO: 5 files to be analyzed
10:03:33.030 DEBUG: Blame file XXXXX
...
10:03:33.182 INFO: 5/5 files analyzed
...
10:03:34.228 INFO: SCM writing changed lines
10:03:34.250 DEBUG: Merge base sha1: cf66888384634f2411429c2829aeb40c1bbf9543
10:03:34.276 DEBUG: Merge base sha1: cf66888384634f2411429c2829aeb40c1bbf9543
10:03:34.287 DEBUG: Merge base sha1: cf66888384634f2411429c2829aeb40c1bbf9543
10:03:34.310 DEBUG: Merge base sha1: cf66888384634f2411429c2829aeb40c1bbf9543
10:03:34.318 DEBUG: Merge base sha1: cf66888384634f2411429c2829aeb40c1bbf9543
10:03:34.338 DEBUG: SCM reported changed lines for 5 files in the branch
10:03:34.338 INFO: SCM writing changed lines (done) | time=110ms
10:03:34.358 INFO: Analysis report generated in 1019ms, dir size=525 KB
steps to reproduce: change a file in a short-lived branch
Is this the intended behavior? For us this renders the “Code coverage in the branch” metric useless.
Before running the Sonarscanner, a git fetch origin develop:develop is done to make sure it is available locally.
Funny thing is that i added the git fetch origin develop:develop to get rid of a new warning that appeared when updating from SonarQube 7.4 to 7.6 about the missing branch:
So the warning is gone but the detection of the actual diff got worse.
Same here, there is just the actual branch being checked out, hence i added the additional fetch of the target branch, but it is not just a shallow clone.
git fetch --unshallow
fatal: --unshallow on a complete repository does not make sense
script returned exit code 128
I have also tried using the sonar-scanner, rather than the gradle scanner plugin. Using the sonar-scanner the problem still persists: Changing 1 line in a file, marks the whole file as new code.
OK, so we can exclude the shallow clone from the problem, thanks.
@Andreas_Petersen I’m not surprised the behavior is the same. All Git related interaction are made by the Git plugin that works in a similar way for all scanners.
The code responsible to find changed lines is:
This is hard for us to investigate, so if you have the opportunity, please get the sources of the sonar-scm-git-plugin in a Java IDE, and attach a debugger to the scanner (using sonar-scanner-debug will automatically start the scanner in debug mode).
Another option would be to share (privately) the copy of your repository so that we could better investigate, but be sure to be allowed to do so.
Add a line in Main.tested() , e.g. a print statement just before the return statement
gradle build
Don’t you commit/push the change in the branch? We are supporting analysis of code in branch/PR that have been pushed to the ALM. Analyzing local changes may lead to unexpected results, since we can’t use integration with the ALM to request missing info.
Just to be clear regarding my previous comment: When I wrote “I forgot writing the commit step”, I mean I forgot writing it in the README on the repo. I did commit, as you can see from my git show in my other previous comment.
The operating system that SonarQube runs on is: Windows 7 Enterprise, Version 6.1 (Build 7601: Service Pack 1)
The operating system that I run the scanner on (my computer): Windows 7 Enterprise, Version 6.1 (Build 7601: Service Pack 1)
Version of the Git plugin: 1.8 (build 1574)
Setting git config --global core.autocrlf false fixed the issue. It now works. Thanks @Julien_HENRY. Perhaps the documentation on branches needs an update to include this information, or perhaps I just missed it?