bazel: Exception running bazel coverage on java tests
Description of the problem / feature request:
“bazel coverage” produces an exception internal to bazel
$ bazel clean --expunge
INFO: Starting clean (this may take a while). Consider using --async if the clean takes more than several minutes.
$ bazel coverage --instrumentation_filter=//src/com/corp/profiles //test/com/corp/profiles:unit
...........
INFO: Analysed target //test/com/corp/profiles:unit (171 packages loaded).
INFO: Found 1 test target...
ERROR: /Users/robfig/alpha/src/com/corp/profileservice/validation2/error/BUILD:3:1: Building src/com/corp/profileservice/validation2/error/liberror.jar (3 source files) failed (Exit 1): java failed: error executing command
(cd /private/var/tmp/_bazel_robfig/1db08896ecff7e5e96a745981c3b77e6/execroot/__main__ && \
exec env - \
LC_CTYPE=en_US.UTF-8 \
external/local_jdk/bin/java -XX:+TieredCompilation '-XX:TieredStopAtLevel=1' -Xbootclasspath/p:external/bazel_tools/third_party/java/jdk/langtools/javac-9-dev-r4023-3.jar -jar external/bazel_tools/tools/jdk/JavaBuilder_deploy.jar @bazel-out/darwin-fastbuild/bin/src/com/corp/profileservice/validation2/error/liberror.jar-2.params)
java.nio.file.DirectoryNotEmptyException: bazel-out/darwin-fastbuild/coverage-metadata/com/corp/profileservice/completion
at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1126)
at com.google.devtools.build.buildjar.instrumentation.JacocoInstrumentationProcessor$2.postVisitDirectory(JacocoInstrumentationProcessor.java:153)
at com.google.devtools.build.buildjar.instrumentation.JacocoInstrumentationProcessor$2.postVisitDirectory(JacocoInstrumentationProcessor.java:143)
at java.nio.file.Files.walkFileTree(Files.java:2688)
at java.nio.file.Files.walkFileTree(Files.java:2742)
at com.google.devtools.build.buildjar.instrumentation.JacocoInstrumentationProcessor.recursiveRemove(JacocoInstrumentationProcessor.java:141)
at com.google.devtools.build.buildjar.instrumentation.JacocoInstrumentationProcessor.processRequest(JacocoInstrumentationProcessor.java:79)
at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.buildJar(SimpleJavaLibraryBuilder.java:140)
at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:118)
at com.google.devtools.build.buildjar.BazelJavaBuilder.processRequest(BazelJavaBuilder.java:105)
at com.google.devtools.build.buildjar.BazelJavaBuilder.runPersistentWorker(BazelJavaBuilder.java:67)
at com.google.devtools.build.buildjar.BazelJavaBuilder.main(BazelJavaBuilder.java:45)
Target //test/com/corp/profiles:unit failed to build
INFO: Elapsed time: 111.911s, Critical Path: 39.00s
FAILED: Build did NOT complete successfully
Executed 0 out of 1 test: 1 fails to build.
$ bazel test //test/com/corp/profiles:unit
INFO: Analysed target //test/com/corp/profiles:unit (0 packages loaded).
INFO: Found 1 test target...
Target //test/com/corp/profiles:unit up-to-date:
bazel-bin/test/com/corp/profiles/unit.jar
bazel-bin/test/com/corp/profiles/unit
INFO: Elapsed time: 26.749s, Critical Path: 22.90s
INFO: Build completed successfully, 139 total actions
//test/com/corp/profiles:unit PASSED in 5.5s
Executed 1 out of 1 test: 1 test passes.
The directory being complained about does not exist under output_path
$ bazel info
output_path: /private/var/tmp/_bazel_robfig/1db08896ecff7e5e96a745981c3b77e6/execroot/__main__/bazel-out
$ ls /private/var/tmp/_bazel_robfig/1db08896ecff7e5e96a745981c3b77e6/execroot/__main__/bazel-out/darwin-fastbuild/coverage-metadata/com/corp/profileservice/completion
ls: /private/var/tmp/_bazel_robfig/1db08896ecff7e5e96a745981c3b77e6/execroot/__main__/bazel-out/darwin-fastbuild/coverage-metadata/com/corp/profileservice/completion: No such file or directory
Feature requests: what underlying problem are you trying to solve with this feature?
Run java tests with coverage enabled
Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
I don’t have an open source reproducer. I was hoping the stack trace would be enough
What operating system are you running Bazel on?
Mac OS High Sierra
What’s the output of bazel info release
?
release 0.9.0
Have you found anything relevant by searching the web?
This appears to be the main discussion about coverage, but it seems to indicate that java coverage is expected to be in working order https://github.com/bazelbuild/bazel/issues/1118
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 2
- Comments: 21 (8 by maintainers)
Commits related to this issue
- Make JavaBuilder use a unique coverage metadata directory for each test instead of the same directory for all the tests. The previous implementation was using one directory for instrumenting the clas... — committed to yext/bazel by iirina 6 years ago
- Make JavaBuilder use a unique coverage metadata directory for each test instead of the same directory for all the tests. The previous implementation was using one directory for instrumenting the clas... — committed to werkt/bazel by iirina 6 years ago
- Make JavaBuilder use a unique coverage metadata directory for each test instead of the same directory for all the tests. The previous implementation was using one directory for instrumenting the clas... — committed to werkt/bazel by iirina 6 years ago
Can I ask why this is not a higher priority? It seems like sort of a big issue in running coverage, and I was under the impression bazel considered java coverage to be production ready. For example, we have to run all of our coverage with j=1, which is a LOT slower than when running the equivalent bazel test at full parallelism. This results in none of the teams wanting to use it.
Or, is there a workaround that I’m not seeing? How do others run coverage without specifying j=1?
Hi Irina, Thanks for the response! The design doc looks very good, and I’m excited at the progress. This particular issue preventing us from being able to reliably run bazel coverage is the main pain point in the current situation, and we can migrate to the new format when it’s ready. I’m very pleased to hear that a fix is being worked on, and I’ll probably cut a personal release as soon as the fix goes in. Many thanks, Rob
(Looking at it again, I figured out that the NoClassDefFoundError was caused by the java_test depending on a java_binary target (accidentally) instead of java_library. It began working after correcting that.)
Running with --experimental_java_coverage solves the NoClassDefFoundError but not the java.nio.file.DirectoryNotEmptyException. At least this means I can run tests with --jobs 1 and have them succeed. Wonderful.