bazelbuild / rules_rust

Rust rules for Bazel
https://bazelbuild.github.io/rules_rust/
Apache License 2.0
654 stars 413 forks source link

Supporting junit XML report in rust_test #1303

Open jgao54 opened 2 years ago

jgao54 commented 2 years ago

Currently rust_test does not support generating junit xml report out-of-the-box.

To support this for all rust test target, a workaround is with the --run_under flag and a script that writes the xml report from stdout to $XML_OUTPUT_FILE:

#!/bin/bash
$@ -Zunstable-options --format=junit --report-time | tee $XML_OUTPUT_FILE

The main downside is having to declare the script as a data dependency for every rust test target.

It would be nice to have built-in support for this in rust_test as an option, would it be sensible to add this to the rust test launcher?

jgao54 commented 2 years ago

Discovered a previous related discussion here. Is this feature still in the roadmap?

UebelAndre commented 2 years ago

The test launcher was actually deleted https://github.com/bazelbuild/rules_rust/issues/1069

But I think it'd be great if rust_test supported junit xml reporting.

jgao54 commented 2 years ago

+ for support for rust_doc_test as well!

UebelAndre commented 2 years ago

If anyone's got context on this, any PRs for this would be welcomed! 😄

keith commented 2 years ago

Note that having a test runner again would potentially help support code coverage as well. Although I'm sure there are downsides

UebelAndre commented 2 years ago

I think my only hesitation to adding a test runner again is breaking the ability to use --run_under for launching debuggers. I'm wondering if this might be something worth opening an upstream feature request for to maybe allow starlark rules to provide a process wrapper that can do some orchestration before running tests but not changing semantics about what binary will be start when a test is run. Does that sound reasonable? Is there a better approach?

ps: https://github.com/bazelbuild/rules_rust/issues/690 is I think related to the topic of process wrappers in my comment here.

keith commented 2 years ago

What orchestration are you thinking for this case?

I wonder if another approach would be to provide some library that could do this generation instead? I don't know rust very well but in apple land there is some infra for being able to observe test results in code, so that can actually be used in process to do this.

jfirebaugh commented 1 year ago

There's an unstable JUnit formatter built in to libtest. Tracking issue: https://github.com/rust-lang/rust/issues/85563