coverageAggregate returns different results each time rerun

[amosschallich]

Just upgraded to 1.0.0 and am very excited about the improvements, especially coverageAggregate.
Currently when I run: sbt coverageAggregate it correctly finds all of my subproject's scoverage.xml files, but then doesn't seem to correctly combine them. One a small number of my classes show up in the aggregate file. (One subfile is 1900 lines, the final aggregate is only 92 lines).
Perhaps an unrelated bug, but the links within the aggregate HTML also don't point to the correct place for me.
Let me know what if any debug information that would be helpful.

[sksamuel]

Other people have reported this too. Also in your subject you said "coverageAggregate returns different results each time rerun", are you saying that the aggregate html is different each time you run it (as opposed to just bring wrong).

[amosschallich]

It is wrong and different each time. If I run it four times I'll get two or three different coverage percentages.

[sksamuel]

Ok thanks. Sounds like its losing statements in the map. I'll investigate.

On 23 November 2014 at 23:05, Amos [email protected] wrote:

It is wrong and different each time. If I run it four times I'll get two
or three different coverage percentages.

—
Reply to this email directly or view it on GitHub
#64 (comment)
.

[agemooij]

I can confirm this. I'm missing more than 75% of my classes in the final report.

[sksamuel]

can you guys check something for me. Is the normal (non aggregated) output the same each time, or does that vary as well ?

[amosschallich]

I hadn't noticed before since the non-aggregated was returning most of what I expected, but it does seem to be varying as well. Two runs and two out of six projects returned different percentages.

[sksamuel]

Did you clean in between ?
On 24 Nov 2014 16:44, "Amos" [email protected] wrote:

I hadn't noticed before since the non-aggregated was returning most of
what I expected, but it does seem to be varying as well. Two runs and two
out of six projects returned different percentages.

—
Reply to this email directly or view it on GitHub
#64 (comment)
.

[amosschallich]

I did not.

[sksamuel]

If I do that i get consistent results I think. Which if true will help me
track down issues.
On 24 Nov 2014 16:45, "Amos" [email protected] wrote:

I did not.

—
Reply to this email directly or view it on GitHub
#64 (comment)
.

[amosschallich]

I ran "clean coverage test" twice and got different results on each.

[sksamuel]

Ok thanks for checking.
On 24 Nov 2014 16:52, "Amos" [email protected] wrote:

I ran "clean coverage test" twice and got different results on each.

—
Reply to this email directly or view it on GitHub
#64 (comment)
.

[massenz]

Just to confirm that, differently from what I reported earlier, the coverageAggregate does not seem to work as intended: I'm just about to push an update to my sentinel project (using sbt-coveralls 1.0.0.BETA1) and you can try it out there.

Essentially the coverageAggregate entirely wipes the top-level results (which were just fine prior to running it).

I'll check out the plugin's code and do some investigation myself, if you can provide any pointer as to the possible area that may cause the issue, it may help out.

[sksamuel]

@agemooij @amosschallich @massenz Can you guys try version 1.0.1 which should address this issue.

[agemooij]

Did you also push the 1.0.1 version of scalac-soverage-plugin?

I got this: unresolved dependency: org.scoverage#scalac-scoverage-plugin_2.10;1.0.1: not found
I guess it might take a while for the jars to propagate but just in case you forgot...

[agemooij]

1.0.1 now works and fixes both problems but unfortunately it also introduces a new one. See the comments on #13 for details.