hi, do I always need to
clean the project before generating the coverageReport? It seems to me that, changing only one line, and then re-generating the report gets me wrong results (everything to 0.0% in my case). Then I just do clean -> test -> coverageReport and it shows "normal" numbers again
because I'm pretty sure the second coverage will re-set it
so typically you'd do coverage; your rest commands; coverageOff
@ckipp:matrix.org I ran the following:
coverage; test; it:test; coverageOff; coverageReporttest scope part
[info] Cleaning datadir [/my-project/target/scala-2.12/scoverage-data]
[info] Beginning coverage instrumentation
[info] Instrumentation completed [456 statements]
[info] Wrote instrumentation file [/my-project/target/scala-2.12/scoverage-data/scoverage.coverage]
[info] Will write measurement data to [/my-project/target/scala-2.12/scoverage-data]it:test scope part
[info] Cleaning datadir [/my-project/target/scala-2.12/scoverage-data]
[info] Beginning coverage instrumentation
[info] Instrumentation completed [18 statements]
[info] Wrote instrumentation file [/my-project/target/scala-2.12/scoverage-data/scoverage.coverage]
[info] Will write measurement data to [/my-project/target/scala-2.12/scoverage-data]coverageReport part
[info] Reading scoverage instrumentation [/my-project/target/scala-2.12/scoverage-data/scoverage.coverage]
to be honest I'm not sure of a solution and I'm currently not actively working on scoverage at all
so I'd recommend commenting on that issue and I can re-open it
Although at that point I could just call
scoverage.report.ScoverageHtmlWriter#write myself I guess
Hmm this codebase seems pretty easy to read, although... case classes with mutable data??
@xkrt I think there's a
coverageDataDir setting or something like that? Can you set it explicitly for the it scope?
Although to aggregate it for the report you might have to do something like I just described
the code base was written like 10 years ago, so there is some outdated stuff in there. the v2 branch is a lot more updated @nafg
regarding the idea of different github actions, that'd be trciky, mainly because all. your code would be instrumented multiple times all with unique ids, meaning that when you try to aggregate everything in the past you might get wonky results
It would be super helpful though. Slick tests take longer than I appreciate (besides SQL server still mostly being tested on appveyor, all the more so once I bring that into github actions) which slows down the feedback cycle of adding to CI
I want each "service" database to be tested in its own job
I'm assuming those are the slow ones
Could I copy this code and modify it somehow? https://github.com/scoverage/scalac-scoverage-plugin/blob/V2/reporter/src/main/scala/scoverage/reporter/CoverageAggregator.scala#L28-L49
Like, get all Statements,
groupBy something more permanent than their id, and somehow merge them
(e.g. sum the
count, && ignored, and if things like start aren't the same throw an error or take any, or include that in the grouping key)
I noticed SBT Remote Cache compile artifacts have the exact same name for regular build and scoverage build modules. I can easily mitigate this by suffixing all my moduleName's when coverageEnabled is true. My question: can this be mitigated in the scoverage plugin or is this an SBT Remote Cache bug for not taking into account build tool config?
I'm not sure I understand? You typically wouldn't want to cache your instrumented code or the other related coverage files
Does a compile with
coverageEnabled := true produce the exact compiled artifacts as coverageEnabled := false?
nope, so when you turn coverage on it will actually add instrumentation to your code and it's compiled with it. so when you run your tests, it "invokes" and records which were invoked
you always want to ensure you turn coverage off then and don't include that code in any artifacts or anything like that
because it will still have the "instrumented" compiled code
and SBT Remote Cache uses the same hash in the artifact-names of both files, so it cannot differentiate between 'instrumented' and clean artifacts.
ahhh well that's the thing they aren't separate, meaning they both don't exist at the same time
like it will just be put where your class files normally will
also keep in mind that if you aren't using the milestone, there are absolute paths in instrumentation files
so again, I don't know your situation, but I'd caution caching anything related to instrumented code or the instrumentation
...or workarounds?
Hi guys,
I'm setting up a scoverage into a multi-module gradle project. It included it before, but it was disabled while the project was updated to scala 2.13.8 (from Scala 2.12).
Now I'm using the gradle-scoverage plugin 6.1.0, with the scoverageVersion set to 1.4.11. This is supposed to support Scala 2.13.8, but I keep getting this error while
runnign reportScoverage task:
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: java.lang.NoSuchMethodError: scala.Predef$.refArrayOps([Ljava/lang/Object;)Ljava/lang/Object;
at scoverage.report.CoverageAggregator$.aggregate(CoverageAggregator.scala:18)
at scoverage.report.CoverageAggregator.aggregate(CoverageAggregator.scala)
at org.scoverage.ScoverageReport$_report_closure1.doCall(ScoverageReport.groovy:51)
at org.scoverage.ScoverageReport$_report_closure1.doCall(ScoverageReport.From what I can gather, this error usually relates to old scala version creating a conflict with the new one. I don't know which part here could cause this mismatch, any ideas?