Hello @rkg,
Welcome to the SonarSource community. 
. I hope you’ll enjoy it.
Although almost everything is possible with SonarQube (with a bit of scripting and use of the Web APIs) I have quite some reservations on the approach.
There seem to be too much emphasis on reporting and, by opposition, not enough on fostering the good use of the product to write clean code.
Such approach is likely to not prompt the correct behaviour of the devs. If they are measured on how much they fix, well:
- They will go for the issues easiest to fix, that will make their reporting look good, rather than the most important issues (and severity is not the first/only criteria to determine the importance of a fix, see the Clean As You Code approach that we promote with our product)
- They will try to hide problems rather than solving them (False Positive or Won’t Fix are not the only options to devs, there are tricks more difficult to track and that can cause problem to fall under the radar)
- They will be tempted to commit without much attention, “artificially” generating issues that they can fix on a 2nd commit, fix the sake to increase the stats on number of issues fixed…
The sooner a issue is fixed the cheaper and safer it is to fix (because it’s fixed when the dev is working on that particular piece of code, with all the context in his head). As such they may ignore issues that SonarLint warn them about, because when fixing a issue raised by SonarLint it’s like fixing an issue before it formally exists (the fix comes before commit in the SCM). That’s a behaviour against the shift left principle that we are very convinced about.
The above are only 2 examples, but by experience there are tons of undesirable behaviours prompted by the approach (to circumvent the reporting).
So, first a strong advice:
- Go back to your management with this feedback:
– A bit of reporting is good, too much reporting will shift the devs attention to the wrong focus (show good stats instead of write clean code)
– Devs should feel SonarQube is a friendly tool to help them, not something potentially used by management to scrutinize their work or (wrongly) measure their performance (the measurement is by experience always biased and incorrect). If they feel scrutinized, the adoption will be (s)low and your code quality will not improve as fast as it could
– Writing clean code is a no brainer. You have to be convinced it’s a must. It does not have to be backed by a made up RoI. Otherwise your code that is a great company asset will inevitably some day turn into a liability (verbatim from the words of our CEO).
OK, now that you have the SonarSource’s vision on this, let’s answer your technical question:
- The features we plan are aligned our vision so there is nothing and there will be nothing in the foreseeable future that could turn away the focus of devs on writing clean code (in a nutshell, there will be no extensive out of the box reporting, beyond what we have right now ie the Portfolios and Projects PDF reports).
- However with the API there is a lot that you can extract from the product that could help you achieving some of the reports you mentioned. The key APIs that you want to look at are:
–api/issues/searchandapi/hotspots/searchto extract issues/hotspots of projects
–api/measures/componentto extract measures/metrics about projects
–api/measures/search_historyto extract the history of metrics/measures of a project
You can have a look at the details of these APIs. The APIs documentation is accessible by clicking on the ? icon top right of your SonarQube platform.
Olivier