Previous_version is not working when i version them as with date

Template for a good bug report, formatted with Markdown:

  • versions used (SonarQube, Scanner, Plugin, and any relevant extension)
    7.9.5

  • error observed (wrap logs/code around triple quote ``` for proper formatting)
    image

  • steps to reproduce
    version has been added and code has been changed in each version

image

  • potential workaround
    Not available and missing the new code from yesterday to today build.

If any alternate please suggest to get the new code status from yesterday build to today build

P.S.: use the #bug:fault sub-category if you’re hitting a specific crash/error , or the #bug:fp sub-category for rules-related behaviour

Hi,

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. :slight_smile:

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?

 
Ann

@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.

Thank you.

Hi,

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.

 
Ann

1 Like

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?

Thank you

Hi,

It’s worth noting here that if your PR adds tests on unchanged code, that’s not going to show up because the code under test isn’t new.

 
Ann

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 ?

Hi,

If what you want is a 1-day New Code Period, that’s a way to get it.

I don’t think number of days works anymore.

 
Ann