We are using the 8.9 LTS Community Edition.
How can we backdate the New Code Period to a date and time before the first analysis?
Developers often create a new repo or branch and a number of commits before pushing to origin.
This means those initial local commits with code changes are being missed as ‘New Code’ when the first push to origin includes commits created prior to the first SonarQube analysis.
Even baselining by checking out the 1st commit, analysing that and then analysing the latest commit will not show the issues that exist in that set of local commits as New Code, although Overall Code issues are incremented on the 2nd analysis. The New Code Period Start line shown in the Activity History graphically shows this start in the right place, but this doesn’t align with the New Code homepage stats which are all 0.
Although we set the New Code Period to be “Previous Version” it actually seems to mean “Date of the Previous Version, as long as it is newer than the last analysis”. Seemingly this is because the SCM compares the code change blame, finds it is earlier than the first analysis (irrespective of the original git commit datetime) and so doesn’t consider it “New”.
Ideally New Code issues against “Previous Version” would be literally that - compared to the analysis with the declared version, and not simply as a computed date. This would make it possible to wind back to an earlier commit, analyse that as a baseline, then analyse a later commit and work out the actual impact of the code between commits.
It is very common for developers to work locally and then push a bunch of commits (eg at the end of the day) and it cannot be relied upon them to push their repo or branch creation at the exact time it is created and before they make code change… usually the first push contains a lot of initial code changes.