Short lived branch versus long lived branch lines to cover

We have a setup where sonar runs against our PRs and then runs again on the long lived master branch after the merge. The issue we are seeing is that on the short lived branch there are 29 lines to cover and we cover 28. This leads to a healthy 96.6% code coverage.

After the merge to master however, the lines to cover drops to 3, with one of those lines being the uncovered one. This gives us 66.7% coverage and a failing quality gate.

Any clue as too what’s going on with the setup that causes the lines to cover to drop like that?

Hi Ryan, can you clarify how the “new code period” is configured?

By default, this new code period is set to “last 30 days” on SonarCloud. If this is the case on your project, an explanation of the current behaviour can be:

  • You started the PR maybe 2 months ago
  • Out of the 29 lines to cover of this PR, 26 were pushed in the first month, and the 3 others in the 2nd month
  • So when you merge, only the 3 last lines are considered as “new” by SonarCloud on the main branch

You can set the “New code period” in the “Administration > General Settings > Settings” page of your project.

1 Like

Hi Fabrice,

That was my original thought as well but, we have our “new code period” at the default 30 days and the PR was only 8 days old.

SonarCloud relies on the blame information to know the last change on a line and therefore to identify if the line should be considered as new or not with respect to the “new code” period. When you look at the code inside SonarCloud (in the “Code” page for instance) and more precisely at the blame information of those 26 lines that should be in the new code period, what blame date can you read? For instance:


1 Like

Git blame has those lines at April 4, 2019 - April 9th, 2019 which seems like they would still be in that 30 day window.

Hummm, this is going to be difficult to debug. Is your project public or private? If it’s private, please feel free to send me the project key in a private message, and we’ll continue there.

1 Like