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.
|