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_
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 releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD?