voonhous opened a new pull request, #19918: URL: https://github.com/apache/hudi/pull/19918
### Describe the issue this Pull Request addresses Part of the CI improvement epic #19524, second bullet of #19528: report the slowest tests per job so the long tail is visible. Stacked on #19909; the commits before "ci: list the slowest tests of each job on the run page" belong to that stack and drop out on rebase. Today the per-class times behind a rebalance have to be pulled out of job logs by hand, and a job's long tail (a 617-second TestColumnStatsIndexWithSQL, a 341-second ITTestRepairsCommand) is invisible unless someone goes looking. ### Summary and Changelog - `scripts/ci/test_timing_summary.py`: walks every `target/surefire-reports` directory, which surefire and the scalatest-maven-plugin both fill with JUnit XML, and prints the slowest classes and the slowest individual tests as Markdown. With `GITHUB_STEP_SUMMARY` set it appends the same text there. Works locally after `mvn test` too. - Every job that runs tests, 14 in bot.yml and 3 in java_ci_engines.yml, gets one step after its test steps, `if: always()`, so the tables appear on the run's summary page for green and red jobs alike. The commented `[CI-TRIM]` lanes get the same step. The two bundle validation jobs run shell scripts, not surefire, and are left alone. ### Impact No change to what runs or how long it takes: the walk prunes below `target/` except `surefire-reports`, and finishes in well under a second on a built checkout. What changes is that the slow tail of every job is one click away on the run page, and the next rebalance reads its numbers from there instead of from log scraping. On the third bullet of #19528, early signal for broken PRs: across 186 recent runs, one was broken at the build step (at least half its jobs failing to compile), and 50 of 2794 job executions failed at their build, almost all isolated download or resolution hiccups. A compile gate ahead of the test jobs would save runner-minutes on about one run in two hundred while adding a queue trip to every run, so it is not proposed here. With the flattened graph a compile failure already surfaces about eight minutes into every job. ### Risk Level low A reporting step that cannot fail the job: `if: always()` runs it after the tests, and a parse error on a report is skipped, not raised. ### Documentation Update none ### Contributor's checklist - [x] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [x] Enough context is provided in the sections above - [x] Adequate tests were added if applicable -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
