what are you trying to achieve: I want to get a correct analysis of new code.
what have you tried so far to achieve this: I configured SonarQube to use my main branch as reference branch, but it still identifies classes that were not changed in a pull request as New Code.
The diff between my branch and the main branch looks like this:
However, SonarQube detects the following as New Code:
Typically when you see old code reported in a pull request, it’s because there was a problem reading the SCM data, which is how analysis determines what’s new. Either that, or the branch being targeted by the PR wasn’t available in the local repository.
If you check the bottom of your analysis log, do you see a message about SCM detection being disabled?
INFO: Parsing the Visual Studio coverage XML report /jenkins-agent/workspace/PR-129/./coverage.xml
INFO: Adding this code coverage report to the cache for later reuse: /jenkins-agent/workspace/PR-129/./coverage.xml
INFO: Coverage Report Statistics: 158 files, 34 main files, 34 main files with coverage, 124 test files, 0 project excluded files, 0 other language files.
INFO: Sensor C# Tests Coverage Report Import [csharp] (done) | time=460ms
INFO: Sensor Zero Coverage Sensor
INFO: Sensor Zero Coverage Sensor (done) | time=13ms
INFO: SCM Publisher SCM provider for this project is: git
INFO: SCM Publisher 8 source files to be analyzed
INFO: SCM Publisher 8/8 source files have been analyzed (done) | time=230ms
INFO: CPD Executor 18 files had no CPD blocks
INFO: CPD Executor Calculating CPD for 28 files
INFO: CPD Executor CPD calculation finished (done) | time=14ms
INFO: SCM revision ID '487...0b'
INFO: SCM writing changed lines
INFO: Merge base sha1: 743...29
INFO: SCM writing changed lines (done) | time=140ms
INFO: Analysis report generated in 258ms, dir size=429.7 kB
INFO: Analysis report compressed in 99ms, zip size=139.9 kB
INFO: Analysis report uploaded in 77ms
The identified commit IDs printed in the log are correctly identified and the branch is cloned as well.
However, sometimes it even does not detect new tests with new coverage: In this example, 359 new lines are discovered and some of them are tested. As you can see, Sonar does not detect the coverage at all, but it loaded the coverage file successfully as shown in the log above.
Of the 359 new lines, 0 were seen as coverable. Perhaps they were comment lines, whitespace, or something else, but they weren’t seen by analysis as needing to be covered. But this is getting a bit far afield from the original topic, so if you’d like to pursue this, please create a new thread.
Regarding the initial question of old code being detected as new, when you look at that old-new code in SonarQube and click in the left margin to get the blame data, what do you see?
It says that the “new code” file has been last changed a month ago (Apr 05th), whereas the current PR was started and opened during the last week. It does not have any changes in those files.
It even identified 2 “Lines to Cover” in an old new Code file that has 100% coverage.
As you can see on the left, under the folder Common/...Helpers/ nothing was changed but SonarQube detected it as New Code as highlighted in on the right. In addition to that, it detected a 100% coverage of that file and detected two additional lines to cover at the same time.
The author of this old New Code is different from the author of the actual New Code. You can also see, that the revision it was changed in was the revision SonarQube detected as the base in the log of the comment above.
I’m not sure what your first screenshot is intended to demonstrate since the two files don’t match. And your second screenshot appears to be of the same, non-matching file.
That’s the thing. SonarQube detected this file to be New Code but it is not, as illustrated by the screenshot with the PR on the left. Because SonarQube detected this file as New Code, the code coverage is wrong and fails the PR check.
So Git blame shows exactly what SonarQube does: that the file was updated on 19 April. SonarQube goes by the SCM blame data, and now we know there was no problem in reading it accurately. So the question is why Git thinks the lines were changed on the 19th. And with that, I can’t help you.
Unfortunately, the log is gone. It’s our live development, and was already merged in the meantime which deletes the CI. The prerequisites are all in place.
I will upload a log, when it appears again.
