mikepenz / action-junit-report

Reports junit test results as GitHub Pull Request Check
https://blog.mikepenz.dev
Apache License 2.0
298 stars 114 forks source link

Improve performance of action's processing #1105

Closed GUI closed 2 months ago

GUI commented 2 months ago

This helps improve the performance of this action with two changes:

  1. One of the main slowdowns seems to be in calling resolvePath() for each test failure (or for each test if include_passed is enabled). This function performs file globbing, which appears to be the main bottleneck, but if you have more than 1 failure per file, it's performing the same globbing lookups repeatedly.

    This introduces a cache so that repeated calls to resolvePath() for the same file only needs to perform the globbing once.

  2. Another area this optimizes is skipping over additional processing logic for passed tests unless include_passed is actually enabled. Previously, various pieces of logic would still be processed for passing tests (like calls to resolveFileAndLine and escapeEmoji), even if include_passed was disabled (the default), so nothing would ever be done with those annotations afterwards. So this optimizes things by never building the annotations to begin with if passed tests are only going to be later ignored.

    The only behavioral change the test suite picked up related to this (which required a change to the test suite) was the fact that parseFile no longer returns annotations for disabled tests by default. But I don't think this actually changes the end behavior of the action, since those disabled tests would then be filtered out afterwards unless include_passed was explicitly enabled.

Benchmarks

I haven't done super rigorous benchmarking, but I was mainly debugging this with a pretty basic test suite with the following numbers of tests:

I was previously using dorny/test-reporter, but I was looking at this action because it did some things differently that I was wanting. However, I noticed the performance differences, and wanted to see if they could be improved.

So with those 579 tests and 11 failures noted above, here were some loose timestamps (according to the GitHub UI) of how long the different actions took to run on 3 separate retry attempts:

I think there's still room for other performance improvements, but I was hoping these couple simpler changes could make a decent difference without changing the behavior or functionality.

Let me know if you have any questions or suggestions. Thanks!

mikepenz commented 2 months ago

Thank you very much for the PR! Will try to come to it as soon as possible.

mikepenz commented 2 months ago

Unfortunately I had to reverse the second commit for v4 of the action. It will be included in v5 as to make it work consistent it will result in some small behavior changes.

thanks again for the great contribution!