`scala_library`es are not Jacoco-instrumented when running coverage for `java_test` (unlike with `scala_test`)

[PawelLipski]

Summary

Our repo uses java_test for running tests written in Scala (some are Scalatests with a JUnit runner, some are vanilla JUnit).

We've noticed that scala_library targets remain completely un-instrumented when running bazel coverage.

Other than that, we don't observe any other major problems with java_test.

Would it be possible to adapt scala_library so that it is properly instrumented when running java_tests? or do you think that it's rather java_test that should be patched in rules_java to handle this case?

Details

I've got a small repro repository where it's pretty easy to see that for some reason, java_test action does not depend on the in Jacoco-instrumented ...-offline.jar output of _phase_coverage.

$ bazel aquery --collect_code_coverage 'outputs(".*-offline.jar", ...)'

action 'JacocoInstrumenter main-offline.jar'
  ...
  Target: //:main
  ...

action 'JacocoInstrumenter test_lib-offline.jar'
   ...
  Target: //:test_lib
  ...

$ bazel aquery --collect_code_coverage 'inputs(".*-offline.jar", ...)'
runfiles for //:scala_test
  Mnemonic: Middleman
  Target: //:scala_test
  ...

### but nothing about :java_test :/

I've also patched the sources of rules_scala locally to check whether JacocoInstrumenter is ever executed:

--- a/src/java/io/bazel/rulesscala/coverage/instrumenter/JacocoInstrumenter.java
+++ b/src/java/io/bazel/rulesscala/coverage/instrumenter/JacocoInstrumenter.java
@@ -24,6 +24,8 @@ import org.jacoco.core.runtime.OfflineInstrumentationAccessGenerator;
 public final class JacocoInstrumenter implements Worker.Interface {

   public static void main(String[] args) throws Exception {
+    if (true) throw new RuntimeException("lolxd");
+
     Worker.workerMain(args, new JacocoInstrumenter());
   }

and as expected, it's executed when running bazel coverage :scala_test, but not for bazel coverage :java_test ☹

[PawelLipski]

Update: the problem is that java_test knows nothing about _CoverageReplacements provider. A jar replacement logic similar to what's in phase_coverage_runfiles would be needed 🤔

@andyscott @johnynek @borkaehw do you think it's doable? The comment in coverage_replacements_provider.bzl suggests that it should be doable in principle:

# The intention is that the final test runner inspects the test
# classpath and replaces artifacts by any mappings found in the
# `replacements` field.

[mkemaldurmus]

Is there any update for this issue? We are facing the same issue.

[PawelLipski]

I've done a crude workaround (to be applied as a patch on rules_scala in our repo): PawelLipski#1