This is an archive of the discontinued LLVM Phabricator instance.

[lit] [PATCH 2/2] Add "--reduced-xunit-report" option
Needs ReviewPublic

Authored by gbedwell on Feb 7 2023, 10:22 AM.

Details

Reviewers
yln
haowei
jdenny
Summary

This option is designed to save on disk space in cases where a CI system
is running dozens of builds each day and is using the information in the
XUnit report to display information about the tests. Due to the sheer
number of tests in the LLVM repo each XUnit report is multiple MB in
size and when multiplied by large numbers of builds these reports can
consume swathes of disk space when each report is archived by CI unless
an aggressive expiration strategy is in place, meaning that historical
data about failures is lost.

In general, the most interesting results are those were a test has
failed (UNRESOLVED/TIMEOUT/FAIL/XPASS) so this new option limits the
report to only include these tests. This comes at the expense of
continuity of test data (a new failure will show as a new test for
example, and no duration data will be recorded for passing tests), but
for some users this may be a trade-off worth making.

I'm not sure whether this would be considered controversial or not as it somewhat breaks the xunit format (although only when the new flag is enabled), so if we ultimately decide not to go with this it's okay. We would definitely find it useful internally though. I've tested it with Jenkins' xunit reporting and it works as I'd expect. I can see all the failures in any given build - just not the passes, and therefore the history isn't as useful. It's an absolute fraction of the size though. This is a trade-off that seems worth it for us.

Diff Detail

Event Timeline

gbedwell created this revision.Feb 7 2023, 10:22 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 7 2023, 10:22 AM
Herald added a subscriber: delcypher. · View Herald Transcript
gbedwell requested review of this revision.Feb 7 2023, 10:22 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 7 2023, 10:22 AM
yln added a subscriber: jdenny.Feb 7 2023, 3:31 PM

Initially, my main question was: would this functionality make sense for reports other than the xml one too? Probably not, because the use case is pretty specific, right? Anyways, I don't think we need to implement that now and leave that work to whoever needs it.

  • 3 small nits
  • Is it possible to write a test for this?

I am okay with the overall motivation considering it's gated behind a flag.

@jdenny: Comments on the larger trade-off of having this feature?

llvm/utils/lit/lit/cl_arguments.py
121

Would something like "report/output failures only" be a more precise flag name?

122

I would prefer to omit the dest=... parameter and let ArgParse pick a Python-idiomatic field name.

llvm/utils/lit/lit/main.py
121

Please pass opts.reduced_report instead of the entire options object here.

yln added inline comments.Feb 7 2023, 3:44 PM
llvm/utils/lit/lit/cl_arguments.py
119

Circling back after reviewing part 1: Can we find a way to pass in the boolean in the constructor for XunitReport to avoid having to extend all write_results() functions for the reports that don't care/support the option?

yln added a reviewer: jdenny.Feb 7 2023, 3:44 PM
jdenny added a comment.Feb 9 2023, 1:14 PM

@gbedwell, thanks for working on this. I have also noticed that gitlab CI's web UI for browsing test results can be tough to navigate for LLVM because of the massive number of tests. This could help.

As you mentioned in the review summary, it is misleading that non-failing tests appear not to have run at all. I'm imagining a manager or some external person looking at CI results and thinking nothing ever passes. To address that issue, one possibility is to add a fake test result per non-failing test code that perhaps sums up its number of tests and elapsed times. I'm not requesting this improvement before this lands. It's just a thought.

Initially, my main question was: would this functionality make sense for reports other than the xml one too?

It might. For lit's own test suite, I noticed the --time-trace-output output is about twice as big as the --xunit-xml-output output when all tests pass. Perhaps the filter can just be moved up a level where write_results is called. It seems like that would also shrink this patch.

@jdenny: Comments on the larger trade-off of having this feature?

Thanks for pinging me on this. Especially if the implementation is moved out of the individual reports, it's a small amount of code, and I can see how it would be useful.

llvm/utils/lit/lit/reports.py
22–23

This list is already in lit/Test.py. It can be accessed with something like test.result.code.isFailure.

Thanks all for taking a look! I haven't had a chance to get back to this yet due to other work landing on my plate, but I intend to revisit this and implement the requested changes ASAP.