Have a general mechanism for collecting code coverage

[iirina]

Code coverage support in Bazel is poor and one reason is the lack of a general mechanism for collecting the code coverage information.

As briefly described in Bazel coverage design doc, the next steps towards a more general solution are:

• Design and implement a coverage_toolchain
• Migrate Bazel builtin C++ code coverage collection to use the new mechanism.

[Toxicable]

@iirina I thought i'd post the instructions you left me here incase someone else is after a way to integrate with bazel coverage in the interm until this is better supported.

---

If the rules are written in Starlark, something helpful can be:

• https://docs.bazel.build/versions/master/skylark/lib/ctx.html#coverage_instrumented
• https://docs.bazel.build/versions/0.23.0/skylark/lib/configuration.html#coverage_enabled
• https://docs.bazel.build/versions/master/skylark/lib/coverage_common.html

Bazel generates coverage reports in the lcov format. To work well with Bazel, your test rules also have to generate lcov reports under COVERAGE_DIR directory. Your test rule has to define the $lcov_merger attrbiute (similar to how Java tests do )

bazel/src/main/java/com/google/devtools/build/lib/bazel/rules/java/BazelJavaTestRule.java

Line 70 in 17794d5

attr("$lcov_merger", LABEL)

[Globegitter]

One thing that came up today - with this design of coverage collection is it possible to have another rule depend on the coverage output? We would like to write another rule that depends on the output and then creates a script that will upload the report on bazel run.

[Toxicable]

@iirina I'm taking another look at this but I havn't been able to figure out how to get COVERAGE_DIR defined.
This is this PR im working in and im running the test npx bazel coverage packages/jasmine/test:coverage_test but the only env var that's defined is LCOV_MERGER becasue I set it with coverage --test_env=LCOV_MERGER=/bin/true bazel-contrib/rules_nodejs#1135

[libratiger]

is there any update for this feature?

[SoftwareApe]

Is there any update on this? We desperately need code coverage with non-lcov tools. Is there at least some workaround where you define your toolchain and keep the instrumentation files and instrumentation executions with arbitrary extensions (e.g. *.csmes, *.o.csmes and *.o.csexe in the case of Squish Coco?

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[SoftwareApe]

Not stale