Why is there no option to define new code as "anything different from the main branch"?

This option is in the documentation for sonarqube Defining New Code | SonarQube Docs but sonarcloud only lets me choose from 4 options of little value.

Previous version
Specific version
Number of days
Specific Date

Specific version is probably the closest but requires me to start versioning CI/PRV builds and those arent going to produce artifacts for deployment so I get to waste version numbers. Not to mention that every time a PR is merged into the main branch I have to bump up the version number here in sonar’s new code definition.

Why isnt the most logical definition of “new code” not a selection for the new code definition?

1 Like

Hi @StingyJack

The New Code definition is only used on main branches.
On Pull Requests, all code changed in the PR is considered as New Code. That’s why the quality gate is still computed on PRs even if it contains conditions on new code and no New Code period.

Here is the New Code documentation for SonarCloud.
I understand your project doesn’t use version numbers for its normal behavior, so to me, the “number of days” seems the better option.

If the new code definition is only for main branches, then why does the PR overview have a New code section?

And why does it seem to based on the delta of commits on that PR branch and not cumulative for the PR branch?

The statistics presented are often confusing or contradictory.

100% of 207 lines covered 207 covered
100% of 58 lines covered 58 covered
100% of 115 lines covered 115 covered
85% of 180 lines covered 153 covered
533 covered of 628 total is ~85%, but the folder lists 54% and the PR overview lists 50%

How is this mathematically possible?

PR Overview indeed mentions “New Code”, but no “Overall code” like the main branch overview does.
It has been made clearer on the New UI (see here to activate it). It also activates a Feedback form, we will be very happy to receive yours.

About the metric computation, coverage percentage includes not only line coverage, but also branch coverage. That’s probably why the values seems inconsistent at the first sight.
Feel free to provide us a public small reproducer with the expected results if you still suspect some computation issues.

That is an awesome feedback tool (with the small exception of the invisible checkbox), and I have used it for the new UI a few times already, but the font is way too small on the new UI for me to use regularly. However it is no different for the page in the screenshot above. There is no way the branch coverage is so oddly awful to drag the percentage down to 50%.

Why would I be shown inconsistent statistics on any page?

if 100% of 207 lines are not covered, why does the screen tell me that?
How can the results of 100%, 100%, 100%, and 85% somehow be averaged into 54%?

Could you please post a screenshot of the Measures > Coverage screen, which shows both the coverage percentage, and the detailed line and branch coverage?

Maybe I can help.

Lines of Code ≠ Lines to Cover. Consider the following code:

if (you.hasAnswer())

There are 8 Lines of Code but only 3 Lines to Cover (you can’t cover a brackcet or the keyword else).

I agree with @Claire_Villard – Checkout the Measures > Coverage tab of your project. It might make it a bit more clear.

1 Like

Lines to cover is flat out wrong on the measurements display.

There are plenty of lines to cover. It’s only considering the constructor as eligible.

Taking SonarCloud out of it entirely – are your coverage reports considering those as lines to cover (and factoring into your coverage tool’s coverage metric)? SonarQube relies on those reports to understand what lines to consider executable.

The actual coverage files are not available to me as they execute on a hosted build agent and they are not published by default. Even when they are I dont have the tools to read them (400+ developers in a company means that we all get VS Pro and not Enterprise). I can run the same coverage tool (coverlet) to see what the files report locally in the main branch.

There are no coverage exclusions configured for this repository.

Sorry if we are going on a tangent here, I only brought up this main branch stats instance because it was also contradictory and was immediately available to me. The recent PR for this also has the same problem; newly added code for the same class depicted above is not being counted as something to be covered (but is being analyzed otherwise and is reporting code smells).