How to check the bugs/code smells from a previous version of the scan?


(Swati Jasuja) #1


I am implementing SonarQube version 6.5 for T-SQL in my project which contains multiple databases and each database again contains multiple sets of procedures, functions, views and triggers that I need to scan.

Since there are some procedures and functions with same name in some of the databases, I need to scan each folder separately. I want to know if there is a way to automatically increment the sonar.projectVersion in the file.
In addition to that, is there a way to check the exact code issues of a previous version scan? Currently, I can only see a graph report showing the number of bugs and code smells of a previous version in comparison to the current version. But cannot see the exact issues of the previous version. If I am scanning each folder seperately with a different version, I would need to go back and check the exact bugs and code smells for that particular scan since the code is different for each scan.

Please suggest.

(G Ann Campbell) #2


It sounds like you need to analyze each folder as a separate project. That means you’ll give each project its own, with a unique project key and name for each. Then you can easily tell which issues came from where.

In fact, what you seem to have in mind is not recommended because any issue raised in the first analysis of a project but not re-found in the second analysis of the project will be Closed as Fixed.

To answer your specific questions:

There’s no way to handle that on the analysis side. If you’re determined enough, you could surely apply automation to it, but again you should really try a different approach altogether.

No, there’s really not. Issues aren’t linked to the analyses in which they were raised except tangentially by date, but even that won’t work well if you’re going to run multiple analyses, one right after the other.