Running coverage on a py_test fails when --java_runtime_version is Java 8

[thirtyseven]

Description of the bug:

The tools in @remote_coverage_tools require a JRE 11 or higher. When running coverage on java_test, the JRE from --tool_java_runtime_version will be used, which enables running the tests themselves with a different JRE. However, when running coverage on py_test, the JRE from --java_runtime_version will be used, so Bazel will fail if --java_runtime_version is a JRE 8.

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Minimal workspace: testrepo.zip

% cd testrepo
% bazel coverage :all
INFO: Invocation ID: 3c462964-cab1-4263-97cb-56fda85d9a68
INFO: Using default value for --instrumentation_filter: "^//".
INFO: Override the above default with --instrumentation_filter
INFO: Analyzed 2 targets (52 packages loaded, 1107 targets configured).
INFO: Found 2 test targets...
FAIL: //:PyTest (see /private/var/tmp/_bazel_tkaplan/5d75f57112c098c59880ccf1af5eecda/execroot/__main__/bazel-out/darwin_arm64-fastbuild/testlogs/PyTest/test.log)
INFO: Elapsed time: 35.944s, Critical Path: 6.98s
INFO: 21 processes: 10 internal, 8 darwin-sandbox, 3 worker.
INFO: Build completed, 1 test FAILED, 21 total actions
//:JavaTest                                                              PASSED in 1.0s
//:PyTest                                                                FAILED in 1.0s
  /private/var/tmp/_bazel_tkaplan/5d75f57112c098c59880ccf1af5eecda/execroot/__main__/bazel-out/darwin_arm64-fastbuild/testlogs/PyTest/test.log

Which operating system are you running Bazel on?

macOS 13.2.1

What is the output of bazel info release?

6.1.0rc1

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 master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[c-mita]

What's the content of the log file for the failing test?

I wonder if this is a simple matter of the :lcov_merger attribute not specifying the host configuration (unlike java test): https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/bazel/rules/python/BazelPyTestRule.java;l=60
https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/bazel/rules/java/BazelJavaTestRule.java;l=60

[thirtyseven]

Apologies, here is the log output:

Executing tests from //:PyTest
-----------------------------------------------------------------------------
GCov does not exist at the given path: ''
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/google/devtools/coverageoutputgenerator/Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)
	at com.google.testing.coverage.JacocoCoverageRunner.getMainClass(JacocoCoverageRunner.java:321)
	at com.google.testing.coverage.JacocoCoverageRunner.main(JacocoCoverageRunner.java:584)
external/bazel_tools/tools/test/test-setup.sh: line 350: 91660 Killed: 9               sleep 10

[thirtyseven]

Another data point: I can't reproduce this on a local build of the latest master, although I can reproduce with a local build of 6.1.0rc1. Will try to bisect.

[thirtyseven]

Looks like Python Starlarkification fixed this, but guessing that's not something cherry-pickable for 6.x:

18955851947002ea39854b5d2aa3e6fa81ef8bf3 is the first bad commit
commit 18955851947002ea39854b5d2aa3e6fa81ef8bf3
Author: Richard Levasseur <[email protected]>
Date:   Mon Feb 13 12:03:42 2023 -0800

    python: Enable Starlark implementation of Python rules
    
    This enables the Starlark implementation of the Python rules. While these are
    largely drop-in replacements, there are a handful of edge cases that
    are known to be incompatible; see https://github.com/bazelbuild/bazel/issues/15897
    for the list of cases.
    
    If you believe the Starlark implementation to be the cause of a problem, please
    post to https://github.com/bazelbuild/bazel/issues/15897.
    
    Work towards #15897
    
    PiperOrigin-RevId: 509295132
    Change-Id: Icbe5beb32e0700a915ac40fe4dbcacf102382974

[thirtyseven]

Confirmed that adding the transition to :lcov_merger also fixes this. Opened #17587

[c-mita]

The error message confirms the issue; Jacoco is running on the coverage generator itself and it shouldn't be.

The Starlark version correctly specifies the exec configuration already.