Code coverage only working with deep directory structure

[sjoerdvisscher]

If I have a file c.scala in package a.b then code coverage only seems to work if its path relative to the BUILD file ends with /a/b/. So it works if the BUILD file is in the root and I have /a/b/c.scala or /src/a/b/c.scala but not /a/b/src/c.scala. It also doesn't work if I have /a/b/c.scala but the BUILD file is in /a or in /a/b. This is only an issue with code coverage, it works fine for building, running and testing.

By "not working" I mean the file doesn't show up in the coverage results, there are no errors.

I found this Jacoco issue that seems related: jacoco/jacoco#939

[liucijus]

Thanks for reporting! It would be great if someone could to volunteer to fix coverage issues in rules_scala. @sjoerdvisscher, any chances you could make a repro on Github?

[sjoerdvisscher]

@liucijus Do you know of an existing example repository, ideally with rules_scala with tests already set up? Or maybe a repro for another bug? A quick Google search didn't turn up anything useful.

[liucijus]

@liucijus Do you know of an existing example repository, ideally with rules_scala with tests already set up? Or maybe a repro for another bug? A quick Google search didn't turn up anything useful.

I have imported some old code from my computer here: https://github.com/liucijus/bazel-scala-tests. See if it is useful.

[sjoerdvisscher]

@liucijus Thanks for that! I have created a repro here: https://github.com/sjoerdvisscher/bazel-scala-tests

[dorranh]

Hi @liucijus and @sjoerdvisscher, I took a bit of time to look at this issue this week, and am pretty confident that the cause of this behavior is the implementation of the JacocoLCOVFormatter class in bazel.

The JacocoLCOVFormatter attempts to map source files to class files in the JAR it is processing using the class's path in the JAR. So in Sjoerd's example, it tries to find the source for "com/github/sjoerdvisscher/coverage/Works.class" by searching the JAR's -paths-for-coverage.txt file for an entry that ends with "com/github/sjoerdvisscher/coverage/Works".

This succeeds for the Works.scala source in this example since its path follows the same pattern as its class, but will fail and be skipped (silently) in the case of the Fails.scala source - the JacocoLCOVFormatter won't find any entries with suffix "com/github/sjoerdvisscher/coverage/Fails" since Fails.scala lives in a different directory.

See the JacocoLCOVFormatter.getExecPathForEntryName() implementation here.

I'm new to bazel, so there might be other options here but I see at least two potential fixes for this. One would be to submit a patch to bazel adding support for a different format for the -paths-for-coverage.txt that allows the src:class path mappings to be explicitly specified. Another could be to reorganize the sources before they get passed to bazel's Jacoco infrastructure such that they follow the package hierarchy it expects.

Do y'all have any thoughts? I'm happy to help implement a fix if it is desired/worthwhile.

Edit: here is some annotated output from the JacocoLCOVFormatter for this example:

You are now in getExecPathForEntryName()...
getExecPathForEntryName(): looking for execPath with suffix /com/github/sjoerdvisscher/coverage/Works.scala
getExecPathForEntryName(): execPath = src/main/scala/Fails.scala
getExecPathForEntryName(): execPath = src/main/scala/com/github/sjoerdvisscher/coverage/Works.scala
getExecPathForEntryName(): Found matching execPath! It was: src/main/scala/com/github/sjoerdvisscher/coverage/Works.scala
You are now in getExecPathForEntryName()...
getExecPathForEntryName(): looking for execPath with suffix /com/github/sjoerdvisscher/coverage/Fails.scala
getExecPathForEntryName(): execPath = src/main/scala/Fails.scala
getExecPathForEntryName(): execPath = src/main/scala/com/github/sjoerdvisscher/coverage/Works.scala
getExecPathForEntryName(): execPath = src/test/scala/ExampleSpec.scala
getExecPathForEntryName(): Didn't find any matches for com/github/sjoerdvisscher/coverage/Fails.scala returning null

[sjoerdvisscher]

@dorranh Thanks for raising this issue in bazelbuild/bazel! I actually just found out the situation is the same for Java, so this is not really a rules_scala issue. I'll see if I can update the repro.