-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Java] Coverage not collected for some manifest jars #21268
Comments
An idea from the sidelines: Since the stub script knows best whether it created a manifest jar, it could pass along its path as an environment variable or Java system property. |
Since the original solution already depends on an environment variable being passed along ( |
When the java classpath exceeds the limit, we create a manifest JAR and pass that on the classpath. JacocoCoverageRunner knows how to extract information from this JAR. But if another JAR ends up on that classpath, it confuses the coverage runner which is expecting only a single jar in this case. This changes the java_stub_template file to export the name of the created manifest jar so the coverage runner can extract it. We also change the template file so the relevant exports don't occur in the middle of a larger function. It's possible this is somewhat overengineered and that we could always rely on the manifest jar always being the first one discovered by the coverage runner, but it is not totally obvious to me that that will always be true. Fixes bazelbuild#21268 Closes bazelbuild#21365. PiperOrigin-RevId: 608333782 Change-Id: I9895689fd9d771c9198e36bef222a9f86ada573e
…Runner (#21413) When the java classpath exceeds the limit, we create a manifest JAR and pass that on the classpath. JacocoCoverageRunner knows how to extract information from this JAR. But if another JAR ends up on that classpath, it confuses the coverage runner which is expecting only a single jar in this case. This changes the java_stub_template file to export the name of the created manifest jar so the coverage runner can extract it. We also change the template file so the relevant exports don't occur in the middle of a larger function. It's possible this is somewhat overengineered and that we could always rely on the manifest jar always being the first one discovered by the coverage runner, but it is not totally obvious to me that that will always be true. Fixes #21268 Closes #21365. Commit a2ebdf7 PiperOrigin-RevId: 608333782 Change-Id: I9895689fd9d771c9198e36bef222a9f86ada573e Co-authored-by: Charles Mita <cmita@google.com>
A fix for this issue has been included in Bazel 7.1.0 RC1. Please test out the release candidate and report any issues as soon as possible. Thanks! |
Can confirm that this fix works with our repository. Thanks all! |
Description of the bug:
When the classpath of a test is over the CLASSPATH_LIMIT, Bazel will create a manifest jar that contains a manifest with an entry of the classpath.
The JacocoCoverageRunner accounts for this and will undo the process to find the classpath during coverage collection. However, one of the checks (urls.length == 1) assumes that the manifest jar is the only jar on the classpath.
If a test has a jar in its
data
, it can also be added to the classpath after the manifest jar. Since the length of the array is greater than 1, the logic is skipped and the coverage collection file is empty.We were able to resolve this by adding a patch to our fork, but the solution depends on the naming convention of the manifest jar from the stub template and also the ordering of the classpath, which may not be the most robust/futureproof solution. I wanted to raise this issue in case Bazel team had a better way to resolve it.
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Created reproduction: https://github.com/ckilian867/bazel-coverage-bug
See README for details
Which operating system are you running Bazel on?
PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"
What is the output of
bazel info release
?$ bazel info release release 7.0.0
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD
?The text was updated successfully, but these errors were encountered: