Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 19 11:40
    prcr edited #5
  • May 19 11:39
    prcr opened #5
  • Apr 21 06:33
    vivekaradshan commented #99
  • Apr 07 09:24
    sparrowt commented #108
  • Mar 27 10:06
    omerlh commented #161
  • Mar 27 09:52
    omerlh commented #161
  • Mar 18 11:46
    andreisilviudragnea synchronize #105
  • Mar 18 11:42
    andreisilviudragnea commented #105
  • Mar 18 11:41
    andreisilviudragnea opened #105
  • Mar 18 11:21
    andreisilviudragnea commented #87
  • Mar 11 10:51
    iaco86 commented #169
  • Mar 08 07:45
    jiushiyaojinqu opened #179
  • Feb 16 20:44
    maiflai commented #178
  • Feb 16 13:58
    vinox1992 opened #178
  • Feb 09 18:05
    sumeetgajjar commented #104
  • Feb 03 06:11
    sumeetgajjar commented #104
  • Feb 03 06:09
    sumeetgajjar opened #104
  • Feb 03 06:01
    sumeetgajjar opened #103
  • Jan 31 08:05
    pgruetter commented #95
  • Jan 31 06:38
    pgruetter commented #95
Chris Kipp
@ckipp:matrix.org
[m]
to be honest I'm not really sure without digging more into it
Blaž Marinović
@bmarinovic
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
Pavel Martynov
@xkrt
Hi guys! My project has test and it scopes. It looks like if I run coverage test and then coverage it:test, the second rewrites measurement data of the first. I want to get "merged" results of test and it scopes coverage. Is it somehow possible?
Chris Kipp
@ckipp:matrix.org
[m]
coverage is sticky, try running it:test after coverage test
because I'm pretty sure the second coverage will re-set it
so typically you'd do coverage; your rest commands; coverageOff
Pavel Martynov
@xkrt
@ckipp:matrix.org I ran the following:
coverage; test; it:test; coverageOff; coverageReport

test 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]
Chris Kipp
@ckipp:matrix.org
[m]
ah yea forgot it still cleans
Pavel Martynov
@xkrt
Note that instrumentation file and measurement data file have the same path for test and it:test scopes and I think the second rewrites the first one. Also, it is strange, but after this run the report is smaller than if I run test and it:test separately:)
Chris Kipp
@ckipp:matrix.org
[m]
what version are you on?
Pavel Martynov
@xkrt
1.9.3
Chris Kipp
@ckipp:matrix.org
[m]
I guess this shouldn't have been closed scoverage/sbt-scoverage#277
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
Pavel Martynov
@xkrt
Looks like the question on stackoverflow is exactly my issue. I use BuildInfo too. Will read it carefully. Thank you!
Pavel Martynov
@xkrt
I've removed "build timestamp" part from BuildInfo, which forces regeneration of BuildInfo.scala on every compilation. After that my scoverage report contains both parts from test and it scopes.
Chris Kipp
@ckipp:matrix.org
[m]
awesome, great
nafg
@nafg
Let's say I want to split up tests into different github actions jobs. How can I combine the coverage data?
nafg
@nafg
I guess I could extract the artifacts into different directories and call scoverage.report.CoverageAggregator.aggregatedCoverage on them, then scoverage.Serializer.serialize the result, then let the sbt plugin take over from there?
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
Chris Kipp
@ckipp:matrix.org
[m]
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
nafg
@nafg
oh I see
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
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)
Thijs Broersen
@ThijsBroersen
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?
Chris Kipp
@ckipp:matrix.org
[m]
I'm not sure I understand? You typically wouldn't want to cache your instrumented code or the other related coverage files
Thijs Broersen
@ThijsBroersen
Perhaps I understand scoverage wrong, but I assumed it adjust compilation. Doesn't it?
Does a compile with coverageEnabled := true produce the exact compiled artifacts as coverageEnabled := false?
Chris Kipp
@ckipp:matrix.org
[m]
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
Thijs Broersen
@ThijsBroersen
aha, ok, so then the answer is yes, I want to cache my instrumented code compile result
and SBT Remote Cache uses the same hash in the artifact-names of both files, so it cannot differentiate between 'instrumented' and clean artifacts.
Chris Kipp
@ckipp:matrix.org
[m]
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
Kevin Esler
@kaesler
I'm seeing a dramatic slowdown of a unit test run apparently due to coverage instrumentation. It takes 10 times as long to run instrumented. Are there any known causes for this?
...or workarounds?
nafg
@nafg
Can scoverage be used with scala 3 yet?
Tobias Roeser
@lefou
Samu Kumpulainen
@Ozame

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?