| Re: [cbi-dev] [platform-dev] Splitting SonarQube analysis? |
|
On 09/23/2014 10:46 AM, Lars Vogel
wrote:
The risk with disabling/excluding some reports (such as coverage) just because they don't actually work is that people forget to re-enable them after and on long-time, we loose some values provided by the tool. On long-term, we want to have coverage reports on test, so we shouldn't disable it. Current lack of coverage metrics is a technical debt that's worth being shown on reports. Currently, the only things that works well with SonarQube for platform build is the code analysis reports (package tangle, rules compliance, documentation...). I believe we should currently focus on those reports, fix those that can be cause for bugs, try to disable those that don't make sense in the case of Platform (such as Array passed directly as method arguements). In parallel, having tests running with tycho-surefire-plugin and enabling Jacoco for coverage reports would make the coverage component of SonarQube more useful. I agree this one is not very relevant. Can you please open a bug a make me a CC ? Sure. But this is not a trivial task to define what is actual technical debt, and what's not. All reports that are not be technical debt for the project could indeed be disabled. But this depends on project, there is no obvious set of rules for a given project. I believe it's worth tracking in a bug to discuss the various rules which make sense and which ones don't. |