1

I had recently integrated sonarqube in our release process. I have set the leak period as the date of integration, and mandated it in quality gate definition that there should be zero new issues since the start of leak period.

The problem is whenever there is a change in a file, sonarqube starts considering all previous issues as new issues. This is especially problematic for large files, as the person who is making any change in a file needs to make all the corrections retrospectively. What I want sonarqube to do is to honor the commit date from the blame information and to define new by comparing commit date with the leak period.

How to make this possible? I am using sonarqube 6.0

azi
  • 929
  • 1
  • 11
  • 31

1 Answers1

2

Your use-case is at the core of the SonarQube Leak Concept. All you need to do is make sure that there is an analysis which corresponds to the start of the Leak Period and which will set the baseline in terms of issues already existing at that point. The right way to do this is to actually use sonar.projectDate (see Analysis Parameters) for that initial analysis. Bottom line:

  • check out the commit which corresponds to integration in your case
  • analyse it by setting sonar.projectDate as the date of that commit and sonar.projectVersion to baseline for example
  • set your Leak Period to baseline
  • for all further analysis, the Leak will correspond to new Issues introduced since that initial baseline. Legacy problems (before integration) will be considered as legacy and not accounted in the Leak Period, your Quality Gate can then do the job as you expect.

FYI SCM blame information is used by SonarQube for auto-assignement of issues and for identification of Coverage on new code, however it can't reliably determine which Issues are new or not: imagine a variable defined and used in your code, if a commit removes its usage then it would raise a variable unused issue on the variable definition, whereas that precise line wasn't touched by any commit. That's why Issues are determined as New relative to the date when SonarQube first detected them (during a previous analysis), hence the workflow detailed above.

Nicolas B.
  • 7,245
  • 17
  • 29