Hi team,
Need your help to shed some light to best approaches.
We currently have a few federated systems containing tons of static code analysis rules. We are hoping to migrate to SonarQube to centralize things, but not sure what the best approach to take here.
Is there a possibility to automate these rules and port them over to SonarQube in one shot?
Cheers,
-David
Hi David,
Welcome to the community
You’ve got two options here. The quickest and easiest is to convert those other other static analysis reports to the Generic Issue Data format, then pass the converted report(s) in to analysis using the sonar.externalIssuesReportPaths parameter. There are a couple limitations to this appropach. As details in those docs I linked:
- they cannot be managed within SonarQube; for instance, there is no ability to mark them False Positive.
- the activation of the rules that raise these issues cannot be managed within SonarQube. In fact, external rules are not visible in the Rules page or reflected in any Quality Profile.
So basically, this acts as a pure pass-through, and if for example you want to stop seeing an external issue (without actually fixing it!) you’ll need to manage the report source to stop reporting the issue.
The longer, harder, but more flexible option is to write a plugin to declare the rules in SonarQube, and read your static analyzers’ reports native formats to raise issues. Do it this way and you get all the benefits of managing rules and issues in SonarQube: regardless of whether or not your external analzyer reports an issue, you can choose whether or not to include it in your analysis by managing the rule’s inclusion or exclusion in the Quality Profile in use. Similarly, you’ll have the ability to mark individual issues Won’t Fix / False Positive.
Hopefully, this is clear and helpful.
Ann