First, it’s incumbent upon me to point out that your version is past EOL. You should upgrade to either the latest version or the current LTS at your earliest convenience. At the moment, they happen to be the same: 8.9.1.
I guess from your screenshot your perceived problem is that there are 0 Lines to Cover in the New Code Period? Can you verify that executable lines were changed in your most recent day/version?
@ganncamp , Thank you for message. Hope you are doing well.
Yes i am working on upgrading the version to latest LTS.
Regarding executable lines, yes. there is change in files. Earlier version (from above screen shot 20210606) have 90% coverage and latest version (20210609) had 92% coverage. In this case, there are code changes and getting executed.
As per my understanding, previous_version will check the last version of code and give the stats in “On new code” . Could you please let me know if anything has to be changed in versioning to get this stats right?
Also if we say like 1 instead of previous_version, is that 24 hours its going to take from the current analysis to check the previous code or how does this no of days parameter is working to get the New code in details.
I don’t doubt there are changes to your files. What I’m asking is what, specifically, were the changes to. There are multiple ways to increase your coverage and one of them is to delete (or comment out) uncovered lines.
You’ve provided a very selective screenshot of your metrics. Here’s a slightly larger shot from our internal analysis of SonarQube itself:
Note the difference between ‘[New] Lines to cover’ and 'New Lines`. Not every changed line is one that can be covered by unit tests, and that’s what that difference illustrates.
thank you @ganncamp . I will execute again and share the report in detail. I am sure that they are commits with unittests which got introduced the latest version and the difference did not come up.
One more query is, can we use the date (YYYYMMSDD) as a version of code and set previous_version as New Code Period / sonar.leak.period two compare the daily builds and get the stat?
or is setting 1 as New Code Period / sonar.leak.period is better? Here just wanted to know what is the time frame this will look for?
Ok Thank you @ganncamp . I am sure it has new code and test cases for the next build.
Did you get a chance to check my query on
One more query is, can we use the date (YYYYMMSDD) as a version of code and set previous_version as New Code Period / sonar.leak.period two compare the daily builds and get the stat?
or is setting 1 as New Code Period / sonar.leak.period is better? Here just wanted to know what is the time frame this will look for? how this can be taken care during the weekend ?