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?
Hi,
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).
Ann
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…
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
- the first analysis will be used as a baseline, and New Code measurements will be made only in comparison to it
- 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 )
Ann
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…
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:
Hi,
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.
Ann