SonarQube v7.9.1 (local instance) Scanner v4.0.0.1744 Plugin SonarPython 1.14.1.3143 (python) OS: Windows 10 v1803 I am experimenting with the leak period and new code. I did a very simple test by uploading two analyses for a small python project, but SonarQube did not report any “New code” (it is equal to zero). What I did exactly: git clone https://github.com/nvbn/thefuck.git cd thefuck git reset --hard 1.13 Create sonar-project.properties with the following content: sonar.projectKey=thefuck sonar.host.url=http://localhost:9000 sonar.login=admin sonar.password=admin sonar.projectVersion=1.13 sonar.leak.period=previous_version Run scanner. See logs: scanner-output-1.13.txt (31.4 KB) Scanner successfully blamed all the .py files. Then: git reset --hard 1.14 Update sonar.projectVersion to 1.14. Run scanner again. See logs: scanner-output-1.14.txt (32.0 KB) Scanner successfully detected changes in 8 files. Here is project dashboard: [image] Looks good. But here are measures of the size: [image] As you can see, “New lines” are reported to be zero. Why?

I already explained how the leak period set to previous_version works, I’m not going to argue it. [image] mmatrosov: Each build has its own build number. My first thought was that I upload each analysis with the version in the form major.minor.patch.build. This means each new analysis will have new projectVersion assigned. Are you trying to say I won’t be able to use previous_version setting in this case, since each new analysis will reset the baseline for comparison? If you want to use the “previous_version” leak period, just override the property project.version with major.minor.patch. Otherwise there are other leak period types you could use as well. The modification date of a line of code is taken from git. So in https://github.com/nvbn/thefuck.git, the lines modified between v1.13 and v1.14 will have a date sometime on Apr 20, 2015. Without specifying projectDate, SonarQube will assign the current date as the analysis date. So no line will be “new” since the modification dates of all lines in the code being analyzed are before the last analysis of the previous version. You’d have to set projectDate to a date that is consistent with the dates when code in v1.13 and v1.14 was modified. Check https://sonarcloud.io/dashboard?id=thefuck. Steps to reproduce: git reset --hard tags/1.13 sonar-scanner -Dsonar.projectKey=thefuck -Dsonar.projectVersion=1.13 -Dsonar.projectDate="2015-04-20T15:49:00+0200" -Dsonar.login= -Dsonar.host.url=https://sonarcloud.io/ -Dsonar.organization= git reset --hard tags/1.14 sonar-scanner -Dsonar.projectKey=thefuck -Dsonar.projectVersion=1.14 -Dsonar.projectDate="2015-04-20T21:49:00+0200" -Dsonar.login= -Dsonar.host.url=https://sonarcloud.io/ -Dsonar.organization= Again, projectDate is only needed when replaying the past. For CI it will work fine without it since the analysis date will be consistent with git commit dates.

Just checked, exactly the same behavior with sonarqube-8.1.0.31237 and sonar-scanner-4.2.0.1873-windows

Hi, If I understood correctly, that’s the expected behavior. Once you change the project’s version, you reset the “new code period”. Meaning that you have a new baseline and from there on what is changed will be considered as “new code”.

I’m sorry, but this does not make any sense to me. I explicitly specify the leak period as “previous_version”. What else could this mean? And of course I upload new analysis each time I bump the version, and only then. This should happen simultaneously in my CI system. Also, not how the screenshot says “New code: since previous version”. BTW, the latest version of Sonar says “New code: since version 1.13”. But the rest is the same. So it explicitly says the new code should be computed since version 1.13. But there are 0 lines of new code!

Sorry, I think my last reply wasn’t very clear. With the “new code period” (or “leak period” as it was called in the past) set to “last version”, all changes included in the first analysis of the new version should be included in the “new code”. I agree that the naming and some labels could be improved as sometimes it might look like the “new code” will include all changes done throughout the previous version (1.13 in your example). And of course I upload new analysis each time I bump the version, and only then This is not the use case the new code period was intended for. If you really want to scan the code only occasionally (which we don’t recommend), you should do it before each release. If you do it like that, all changes introduced in the version about to be release will be in the “new code”. Anyway, I suspect that your test didn’t give the results you expected because you are analyzing versions in the past. Imagine the following scenario: Last analysis of v1.13 was done 5 min ago Analysis of v1.14 is done now. SonarQube will detect the version change and will consider all lines that were modified later than 5min ago to be “new”. The problem here is that SonarQube gets the modification date of each line using git. In this case since this is code modified years ago, no line will be marked as “new”. If you want to replay the past, you can try using sonar.projectDate. More info here: https://docs.sonarqube.org/latest/analysis/analysis-parameters/

Hi, Duarte, With the “new code period” (or “leak period” as it was called in the past) set to “last version”, all changes included in the first analysis of the new version should be included in the “new code”. That’s not what happened to me. “The new version” was 1.14 for me. Which included quite some changes. But Sonar showed 0 lines of new code. I agree that the naming and some labels could be improved as sometimes it might look like the “new code” will include all changes done throughout the previous version (1.13 in your example). That’s what I would expect, and from my point of view, this statement contradicts your previous paragraph. I am not alone in this understanding. Here the quote from a tutorial, which shows up as the first link in google if you search for “previous_version”: By using the previous_version setting, the New Code Period will be tracked from the previous version set with the sonar.projectVersion parameter. Yeap, that’s exactly what I would expect. Here is the quote from your docs: Previous Version – The New Code Period defaults to Previous version which shows any changes made in your project’s current version. This works well for projects with regular versions or releases. Seems like this is closer to what you are trying to explain, but it is totally unexpected and still not clear to me. The docs do not help, there are not much info on how this feature works, which is annoying. Here is our workflow, which I think is quite usual. We have a CI system set up, and it builds the software several times a day. Each build has its own build number. My first thought was that I upload each analysis with the version in the form major.minor.patch.build. This means each new analysis will have new projectVersion assigned. Are you trying to say I won’t be able to use previous_version setting in this case, since each new analysis will reset the baseline for comparison? Now, I tried to upload several analyses under the same version. Essentially, I repeated the same steps I described originally, but did not change projectVersion. But this does not work either! I still see zero lines of new code! [image] [image] Now I am really confused. I see this nice mark “New Code Period starts here” in the activity pane. I can clearlly see how Lines Of Code metric went up in the chart on the right. But there are still 0 lines of new code in Measures pane! Anyway, I suspect that your test didn’t give the results you expected because you are analyzing versions in the past How is this related, if I specify leak period as previous_version? The problem here is that SonarQube gets the modification date of each line using git. In this case, since this is code modified years ago, no line will be marked as “new”. I’d expect Sonar works the same way for both analyses I made. Both times I was analyzing code from git. I don’t get how this is related. I assume that when I set the leak period in days, only in this case the “age” of code starts to matter. And the “birth date” of a line of code is the moment an analysis was uploaded to the server. Unless overridden by projectDate setting. Is this correct? Or is it actually determined by the date in git?

Ah, finally, I was able to reproduce your example on my machine. Thanks a lot! Without specifying projectDate, SonarQube will assign the current date as the analysis date. So no line will be “new” since the modification dates of all lines in the code being analyzed are before the last analysis of the previous version. Well, it would be nice if it was in the docs. This is not obvious. The docs on the leak period are very shallow in my opinion. Anyway, thanks for your help.

New Lines is equal to zero, even though SCM seems to work

SonarQube Server / Community Build

mmatrosov (Mikhail Matrosov) January 29, 2020, 1:18pm 8

I tried again with leak_period set to 1. I uploaded versions 1.13, 1.14 and 1.15, with sonar.projectDate set to 1st, 2nd and 3rd of January. Again, activity tab shows what I want, while New Lines under Measures tab is zero:

Topic		Replies	Views
New Code period not being respected if there is no initial version SonarQube Server / Community Build sonarqube	6	3405	November 15, 2018
SonarQube new lines are not correct SonarQube Server / Community Build sonarqube , scanner	4	6357	June 23, 2020
All New code not detected when using Previous version SonarQube Server / Community Build sonarqube , coverage , new_code	35	608	October 5, 2026
My numbers don't add up SonarQube Server / Community Build sonarqube , msbuild , coverage	8	1137	April 14, 2020
Using new code "since previous version" instead of "since BASELINE" SonarQube Server / Community Build sonarqube	26	15639	August 6, 2020

New Lines is equal to zero, even though SCM seems to work

Related topics