bazel icon indicating copy to clipboard operation
bazel copied to clipboard

[Java] Coverage not collected for some manifest jars

Open ckilian867 opened this issue 1 year ago • 3 comments

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_

ckilian867 avatar Feb 08 '24 23:02 ckilian867

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.

fmeum avatar Feb 08 '24 23:02 fmeum

assigning to @c-mita as this is from https://github.com/bazelbuild/bazel/commit/94eeea6486ebbc2672be9dc60b0c8f6464276984

hvadehra avatar Feb 09 '24 08:02 hvadehra

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.

c-mita avatar Feb 13 '24 13:02 c-mita

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!

iancha1992 avatar Feb 22 '24 22:02 iancha1992

Can confirm that this fix works with our repository. Thanks all!

ckilian867 avatar Feb 27 '24 03:02 ckilian867