How to make leak=overall


(Roy Sela) #1

I’m running a scan over an existing project and I’d like the leak period to reflect the overall issues/coverage (management decision to focus on the overall issues for the time being) so i’ve tried to set the leak period setting to previous_version and run an empty scan with projectVersion=1, followed by a regular scan with projectVersion=2, but for some reason that didn’t work… am I doing it the wrong way? is there an easier way to do it?

(G Ann Campbell) #2


If you really want to focus on overall… the facile answer is just focus on overall. What I mean by that is adjust your Quality Gate conditions to be on overall numbers rather than on New Code values, and pay more attention to the white (overall) part of the project homepage than the yellow (new code).


(Roy Sela) #3

Yeah I know but the organization level is focused on the leak time while that particular project shouldn’t (for now), so I don’t want to change the quality gate rather than really have this project’s leak period pointing to the overall data…

(G Ann Campbell) #4

Well… there’s no non-hacky way to put all code in the New Code period. Even if you set your New Code Period to some static date before the first analysis

  1. the first analysis will be used as a baseline, and New Code measurements will be made only in comparison to it
  2. issues will still be backdated in many circumstances

The only (very hacky) way I can see to do this is to initialze your SonarQube project with an essentially empty analysis, set it as baseline, and then start analyzing your real project.

IMO, if your Organization is focused on the New Code Period but your Management insists on Overall your best option is really a different QG. And your Management can handle justifying why it’s needed (and maybe be informed by the Organization that it’s really not :smile:)


(Roy Sela) #5

This is why I tried working with versions rather than dates as the basis of my leak period, as I wrote in my first message, running an empty scan (v1) followed by regular scan (v2) didn’t work as expected - resulting in overall issues but nothing in the leak period. I tried it as this is an existing project and not a fresh one, maybe it would be simpler to delete and re-create the project…

(Roy Sela) #6

I think this issue is turning into a defect rather than an unorthodox usage… I ran an almost-zero scan (V1, containing only index.js & config.js) which found no issues, then a regular scan (V2, containing all the source folder) which found 5 issues, yet these issues are not considered as leak period issue…

Activity report showing the new issues as part of the new version:

(Roy Sela) #7

The project overview:

(G Ann Campbell) #8


What version of SonarQube are you using? And if you would, please check the last modified dates of your issues against the dates assigned to the issues themselves.


(Roy Sela) #9

I’m using SonarCloud…

Regarding the issues - it seems like all of the scan history is maintained although the actual scans were removed, i guess this is why they are not considered new issues even though they should…