bazel
bazel copied to clipboard
[Java] Coverage not collected for some manifest jars
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
returns development 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
?
$ git remote get-url origin; git rev-parse HEAD
https://github.com/ckilian867/bazel-coverage-bug.git
a1570f38065822f548cd279eb7e3bf75257d8a59
### Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
_No response_
### Have you found anything relevant by searching the web?
https://github.com/bazelbuild/bazel/issues/11847
### Any other information, logs, or outputs that you want to share?
_No response_
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.
assigning to @c-mita as this is from https://github.com/bazelbuild/bazel/commit/94eeea6486ebbc2672be9dc60b0c8f6464276984
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 ($JACOCO_IS_JAR_WRAPPED
), it could probably just pass the name of the wrapped jar instead.
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!