Coverage for java_test doesn't handle external jars #13376
Labels
Comments
ulfjack
added a commit
to ulfjack/bazel
that referenced
this issue
Apr 19, 2021
When java_test rules are run with coverage, then Bazel writes a file
containing the runtime classpath using root-relative paths.
The collect_coverage.sh script then processes that file to generate
another file containing absolute paths by prefixing each of the paths
with the runfiles directory and the workspace name. It then runs the
singlejar tool on this list of jar files to merge them into a single
file.
This happens to work for all jar files in the main repository because
the runfiles path is the runfiles directory plus the workspace name
plus the root-relative path.
However, it is broken if some of the jar files come from an external
repository. It appears that singlejar errors out on the first such jar
file, generating a partial output jar file without a central directory.
The error is swallowed by the `collect_coverage.sh` script. Presence of
coverage results may thus depend on the order of classpath entries.
In order to fix this, we change the runtime classpath file to contain
runfiles-relative paths, and the coverage script to prefix them with
the runfiles directory.
Note that we reuse SourceManifestAction here, i.e., the identical code
that is also responsible for generating the runfiles directory in the
first place. This is the only reliable way to get the correct paths
into the test action.
There are more places that use `LazyWritePathsFileAction` and I suspect
that all of them are broken:
- persistent test runner support in BazelJavaSemantics (AFAIK, this
doesn't work in Bazel anyway)
- coverage w/ metadata jars in BazelJavaSemantics (not used by
JavaBinary)
- coverage source list file ('-paths-for-coverage.txt'); this probably
results in non-functioning coverage for *source files* in external
repositories
Fixes bazelbuild#13376.
Change-Id: Ie9bcc92344f06e190efcb192a3b6ef9905aea352
|
cc @c-mita This looks related to #13358 (comment). I think the same incorrect paths have started causing errors with JDK 16, patching in your fix also resolves that issue with JDK 16 for me. |
katre
pushed a commit
that referenced
this issue
Jul 12, 2021
When java_test rules are run with coverage, then Bazel writes a file
containing the runtime classpath using root-relative paths.
The collect_coverage.sh script then processes that file to generate
another file containing absolute paths by prefixing each of the paths
with the runfiles directory and the workspace name. It then runs the
singlejar tool on this list of jar files to merge them into a single
file.
This happens to work for all jar files in the main repository because
the runfiles path is the runfiles directory plus the workspace name
plus the root-relative path.
However, it is broken if some of the jar files come from an external
repository. It appears that singlejar errors out on the first such jar
file, generating a partial output jar file without a central directory.
The error is swallowed by the `collect_coverage.sh` script. Presence of
coverage results may thus depend on the order of classpath entries.
In order to fix this, we change the runtime classpath file to contain
runfiles-relative paths, and the coverage script to prefix them with
the runfiles directory.
Note that we reuse SourceManifestAction here, i.e., the identical code
that is also responsible for generating the runfiles directory in the
first place. This is the only reliable way to get the correct paths
into the test action.
There are more places that use `LazyWritePathsFileAction` and I suspect
that all of them are broken:
- persistent test runner support in BazelJavaSemantics (AFAIK, this
doesn't work in Bazel anyway)
- coverage w/ metadata jars in BazelJavaSemantics (not used by
JavaBinary)
- coverage source list file ('-paths-for-coverage.txt'); this probably
results in non-functioning coverage for *source files* in external
repositories
Fixes #13376.
Change-Id: Ie9bcc92344f06e190efcb192a3b6ef9905aea352
Closes #13377.
Change-Id: Ie9bcc92344f06e190efcb192a3b6ef9905aea352
PiperOrigin-RevId: 369687409
katre
pushed a commit
to katre/bazel
that referenced
this issue
Jul 13, 2021
When java_test rules are run with coverage, then Bazel writes a file
containing the runtime classpath using root-relative paths.
The collect_coverage.sh script then processes that file to generate
another file containing absolute paths by prefixing each of the paths
with the runfiles directory and the workspace name. It then runs the
singlejar tool on this list of jar files to merge them into a single
file.
This happens to work for all jar files in the main repository because
the runfiles path is the runfiles directory plus the workspace name
plus the root-relative path.
However, it is broken if some of the jar files come from an external
repository. It appears that singlejar errors out on the first such jar
file, generating a partial output jar file without a central directory.
The error is swallowed by the `collect_coverage.sh` script. Presence of
coverage results may thus depend on the order of classpath entries.
In order to fix this, we change the runtime classpath file to contain
runfiles-relative paths, and the coverage script to prefix them with
the runfiles directory.
Note that we reuse SourceManifestAction here, i.e., the identical code
that is also responsible for generating the runfiles directory in the
first place. This is the only reliable way to get the correct paths
into the test action.
There are more places that use `LazyWritePathsFileAction` and I suspect
that all of them are broken:
- persistent test runner support in BazelJavaSemantics (AFAIK, this
doesn't work in Bazel anyway)
- coverage w/ metadata jars in BazelJavaSemantics (not used by
JavaBinary)
- coverage source list file ('-paths-for-coverage.txt'); this probably
results in non-functioning coverage for *source files* in external
repositories
Fixes bazelbuild#13376.
Change-Id: Ie9bcc92344f06e190efcb192a3b6ef9905aea352
Closes bazelbuild#13377.
Change-Id: Ie9bcc92344f06e190efcb192a3b6ef9905aea352
PiperOrigin-RevId: 369687409
katre
pushed a commit
to katre/bazel
that referenced
this issue
Jul 13, 2021
When java_test rules are run with coverage, then Bazel writes a file
containing the runtime classpath using root-relative paths.
The collect_coverage.sh script then processes that file to generate
another file containing absolute paths by prefixing each of the paths
with the runfiles directory and the workspace name. It then runs the
singlejar tool on this list of jar files to merge them into a single
file.
This happens to work for all jar files in the main repository because
the runfiles path is the runfiles directory plus the workspace name
plus the root-relative path.
However, it is broken if some of the jar files come from an external
repository. It appears that singlejar errors out on the first such jar
file, generating a partial output jar file without a central directory.
The error is swallowed by the `collect_coverage.sh` script. Presence of
coverage results may thus depend on the order of classpath entries.
In order to fix this, we change the runtime classpath file to contain
runfiles-relative paths, and the coverage script to prefix them with
the runfiles directory.
Note that we reuse SourceManifestAction here, i.e., the identical code
that is also responsible for generating the runfiles directory in the
first place. This is the only reliable way to get the correct paths
into the test action.
There are more places that use `LazyWritePathsFileAction` and I suspect
that all of them are broken:
- persistent test runner support in BazelJavaSemantics (AFAIK, this
doesn't work in Bazel anyway)
- coverage w/ metadata jars in BazelJavaSemantics (not used by
JavaBinary)
- coverage source list file ('-paths-for-coverage.txt'); this probably
results in non-functioning coverage for *source files* in external
repositories
Fixes bazelbuild#13376.
Change-Id: Ie9bcc92344f06e190efcb192a3b6ef9905aea352
Closes bazelbuild#13377.
Change-Id: Ie9bcc92344f06e190efcb192a3b6ef9905aea352
PiperOrigin-RevId: 369687409
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the problem / feature request:
In a Java build using jars from external repositories, running coverage may drop some coverage results due to incorrect path computations.
Bazel writes a file containing the runtime classpath using
LazyWritePathsFileAction. Thecollect_coverage.shscript then processes that file to generate another file containing absolute paths by prefixing each of the paths with the runfiles directory and the workspace name. It then runs the singlejar tool on this list of jar files to merge them into a single file.However, for jar files outside the main repository, this results in incorrect paths such as
.../MyTest.runfiles/workspace/guava.jar, where the correct path should be.../MyTest.runfiles/guava/guava.jar.Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
What operating system are you running Bazel on?
Seems to be OS-independent.
What's the output of
bazel info release?This happens with 4.0.0 and also HEAD.
Any other information, logs, or outputs that you want to share?
I have a patch that fixes the paths for coverage w/
java_test. However, theLazyWritePathsFileActionis used in three more places, and I suspect all of them are incorrect.The text was updated successfully, but these errors were encountered: