| 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.So my question is how can I exclude the tests from being reported as not covered by tests.
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 ?Also EPartServiceTest is the main villain for having public undocumented API, which is also non sense.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.These are only examples, more can be easily found and I think Sonor should be configured to give more reasonable information, if possible.
I believe it's worth tracking in a bug to discuss the various rules which make sense and which ones don't.
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cbi-dev