Konubinix' opinionated web of thoughts

Sonar New Code Definition

Fleeting

sonar new code definition

New code definition
Apart from pull requests (where all code changes are considered new code) SonarCloud also encourages you to specify a new code definition for other contexts within their project. The details of this definition depend on your project, but the aim is to encompass code changes that are part of the current phase in development. For example, for projects that have explicit versioning of releases, the new code definition can be set as “everything that has changed since the last version bump”. Alternatively, for projects that work on the principle of continuous delivery (i.e., they have no versions) other criteria are available to define new code.

— https://sonarcloud.io/documentation/improving/clean-as-you-code/

Quality gates on pull requests work a bit differently. They take into account only the code that was changed by the pull request. They do not use the project new code definition.

— https://sonarcloud.io/project/overview?branch=somebranch&id=someproject

ambiguity in computing the new code in sonarqube

The sonar client/server architecture implies that there are two kind of dates.

  1. the date of submission of the analysis (the sonar.projectDate value),
  2. the date of SCM annotation in the analysis.

In the classical flow, you don’t have to worry about those. But there are several edge cases in which the difference might lead to counter intuitive results.

For instance, if the git commits and the computer doing the analyse don’t have synchronised clocks, you can submit analysis and find no new code at all.

I keep saying 5 hours because any new code which is analyzed after it is treated as new code, and anything before that is never considered as new code (It doesn’t matter how many times you run like 100 or 200).

– https://community.sonarsource.com/t/sonarqube-new-code-analysis-is-off-by-5-hours/43564

Also, when trying to replay the past, without using projectDate, no new code will be found.

So in https://github.com/nvbn/thefuck.git, the lines modified between v1.13 and v1.14 will have a date sometime on Apr 20, 2015. Without specifying projectDate, SonarQube will assign the current date as the analysis date. So no line will be “new” since the modification dates of all lines in the code being analyzed are before the last analysis of the previous version. You’d have to set projectDate to a date that is consistent with the dates when code in v1.13 and v1.14 was modified.

Check https://sonarcloud.io/dashboard?id=thefuck.

Steps to reproduce:

git reset --hard tags/1.13
sonar-scanner -Dsonar.projectKey=thefuck -Dsonar.projectVersion=1.13 -Dsonar.projectDate="2015-04-20T15:49:00+0200" -Dsonar.login=<token> -Dsonar.host.url=https://sonarcloud.io/ -Dsonar.organization=<org>
git reset --hard tags/1.14
sonar-scanner -Dsonar.projectKey=thefuck -Dsonar.projectVersion=1.14 -Dsonar.projectDate="2015-04-20T21:49:00+0200" -Dsonar.login=<token> -Dsonar.host.url=https://sonarcloud.io/ -Dsonar.organization=<org>

Again, projectDate is only needed when replaying the past. For CI it will work fine without it since the analysis date will be consistent with git commit dates.

– https://community.sonarsource.com/t/new-lines-is-equal-to-zero-even-though-scm-seems-to-work/19099/8

sonar new code definition is not adapted to the pragmatic git workflow

Due to the ambiguity in computing the new code in sonarqube, version released in short-lived branch will make sonar stop looking at your main branch once it is merged.

Guess that you are working on the develop branch, in which there are plenty of errors and the quality gate is red. Imagine that at some point you need to release a bugfix release.

The sensible way of doing it is:

  • start a branch release/X out of develop at the point of the previous release
  • fix the bug -> sonar scans will show the difference against the develop long-lived branch at that time
  • tag the version X
  • merge the bugfix in the develop branch
  • now the new « previous » version is X and changes prior to X will stop being part of the quality gate.

Then, the quality gate of develop suddenly becomes green, everything is seemingly ok.

Notes linking here