Analysing the cause of drop in issue numbers

SonarQube Cloud
, , ,
1

After checking the project overview page, I noticed that in a matter of 5 day (including 2 weekends) there was a huge drop in number of project issues (from 4244 to 3109):

How can I proceed to understand what happened there? There seems to be no way to link the events in the list view on the left of the screenshot to project commits or otherwise link to any code changes. How can I identify the parameters (branch/PR, commit, user) of the scan that caused the drop in issue numbers?

P.S. I found that I can filter issues by status/resolution, but the issues returned by these filters still lack timestamp and VCS information to link them to the specific time frame or code change.

2

Hi,

Unfortunately, this is likely to be tough to track down. A change in issue count could be caused by

  • use of a different profile (would be an event, but listed for completeness)
  • change in profile contents, i.e. same profile, different rules
  • change in rule implementation, i.e. same rules, different logic
  • change in analysis scope configuration: sonar.sources, inclusions, exclusions, etc.
  • change in what’s available to analysis (problem with checkout?)

Additionally, given the slope on that graph, I think it’s quite likely that the exact analysis where this changed fell victim to housekeeping.

I can think of two places I would look for a thread you might be able to pull on to unravel this.

  • Look at Closed issues in the project
    • Are they in files that still exist in the project on the SonarCloud side?
    • Are they raised by rules still being applied to the project?
  • Compare job logs from before and after the change. Are there any notable differences?

You don’t mention the project language(s) but it may also be worth checking the language announcements for “we fixed false positive” announcements on or after 27 June.

 
HTH,
Ann

4

You don’t mention the project language

It’s C++

Look at Closed issues in the project

No way to restrict the search by closing date, right?

Compare job logs from before and after the change.

I guess you mean CI logs from the job that ran SonarScannerCLI, right? Or is there somewhere in the SonarCloud where I can look for more insights?

5

Hi,

No. Only by attribution date. (The issue’s blame date, versus the date of the analysis that created it.)

Yes, the CI logs. Sorry, I still tend to default to Jenkins terminology.

 
Ann

10

Hi again,

One more more thing to consider, since this is C++, is the build. Are you using the build wrapper? And if so, do you always do a clean build? Because with the build wrapper only what’s built is analyzed. Or is it possible the build itself changed and some files are no longer included/used?

 
Ann