search

trautonen / coveralls-maven-plugin

Maven plugin for submitting Java code coverage reports to Coveralls web service.
MIT License
311 stars 124 forks source link

Merge coverage results from serveral report files #78

Closed psiniemi closed 9 years ago

psiniemi commented 9 years ago

We have a use case where we have separate coverage reports from integration tests and unit tests for both javascript and java. This means the same file will appear in several reports. Current plugin implementation only counts the first occurrence of a file. This pull request keeps sources in memory until all reports have been parsed and only writes them in the end to enable merging the results.

Use case here: https://bob.nitorio.us/jenkins/job/willow-integrationtests/

trautonen commented 9 years ago

Thanks @psiniemi, this has been on my own todo list for a while. There are few thing to consider before straight applying this (and the reason why I haven't implemented it, of course after lazyness).

If you have large codebase and all the source contents are kept in memory it might become an issue for the CI server. But Coveralls is not using the provided sources anymore, because they are relying loading the contents straight from github. They haven't published any information about the API usage regarding the source contents, but I could try to ask them or just test what happens if the actual sources are just left out from the API calls.

Another issue relates to #56 which I'm not sure I can easily solve. Merge of the coverage from multiple sources might actually result merging coverage of two different source files which shouldn't be merged. I'll try to look what are the options and if there are no viable way to detect where the source file comes from, I'll just do this the way it is now. Then we have to live with the fact that this plugin does not support multi module projects with sources using the same fqn.

psiniemi commented 9 years ago

Thanks for the prompt response. Here's my thoughts: The only thing consuming real memory would I think indeed be the actual source. One option for that would be to only read the source when it is written into the report, since it's not used in any of the analysis prior to that. The report wouldn't have to change. So instead of storing the source as a string in the Source object, just store a file reference that is checked for existence and readability.

As for the multimodule with colliding fqn:s - IMHO it's a corner case that should not trounce a more common use case these days. I think it should be solved by splitting the modules into independent projects.

psiniemi commented 9 years ago

One other thing of note: for multimodule builds with colliding fqn:s the current implementation will only count the first class with the same fqn, so I don't think the functionality degrades here significantly.

trautonen commented 9 years ago

Done in #81.