[Bug]: Tests are broken --experimental_split_coverage_postprocessing

[joeljeske]

What happened?

With bazel 6.1.0, run a test with code coverage with RBE and flags:

• --remote_download_minimal
• --experimental_split_coverage_postprocessing
• --experimental_fetch_all_coverage_outputs
  And see an error like

EDIT: This bug is reproducible locally, with the above flags

FATAL: the entry_point '$BAZEL_OUTPUT_BASE/sandbox/linux-sandbox/17885/execroot/$REPO_NAME/bazel-out/k8-fastbuild/bin/...TARGET_PATH.../../aspect_rules_js/js/private/coverage/coverage.js' not found in runfiles

Version

Development (host) and target OS/architectures:

Output of bazel --version: 6.1.0

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:

3530bb6

How to reproduce

No response

Any other information?

No response

[alexeagle]

Looks like @thesayyn likely knows this the best, #238

[joeljeske]

I think its this line here,

rules_js/js/private/js_binary.bzl

Lines 461 to 463 in 809ce7f

	# We have to propagate _lcov_merger runfiles since bazel does not treat _lcov_merger as a proper tool.
	# See: https://github.com/bazelbuild/bazel/issues/4033
	runfiles = runfiles.merge(ctx.attr._lcov_merger[DefaultInfo].default_runfiles)

I think that by using --experimental_split_coverage_postprocessing that Bazel allows the custom lcov_merger binary to handled properly. At action-time, I see the coverage.js in the merger.runfiles tree, but not in the test.runfiles tree.

[joeljeske]

I am able to workaround the issue by conditionally selecting the proper runfiles tree after the shared runfiles code picks the wrong one. I don't think this is the right solution, but it does fix the issue and allow for use with/without experimental_split_coverage_postprocessing.

01-fix-coverage-split-action-issue-965.patch

[thesayyn]

a patch for the coverage is on #993. I'll leave the issue for tracking purposes. further work is blocked on bazelbuild/bazel#18017