wombatu-kun commented on code in PR #19514: URL: https://github.com/apache/hudi/pull/19514#discussion_r3717550973
########## .github/workflows/bot.yml: ########## @@ -32,6 +32,13 @@ env: FLINK_IT_FILTER2: -Dit.test=!ITTestHoodieDataSource jobs: + # [CI-TRIM] to revisit for CI improvement + validate-ci-baseline: Review Comment: Following up on the `validate-ci-baseline` thread with a number, since it also changes the rebase ask in #19515. Because the baseline job sits in `bot.yml`, a pre-trim PR cannot pick up the new context without triggering the whole workflow. I measured a recent full run at 2,610 runner-minutes (43.5 h); summing the same per-job times over the 17 surviving matrix entries gives an estimated ~10 h per run. So reviving one pre-trim PR costs roughly that, for a required check that is a single `echo`. There are 506 open PRs, which puts the full sweep at ~5,000 runner-hours, above the 3,600 h five-day limit on its own. Combined with the point above, the job currently pays the cost of the test jobs without gating on any of them. Would it work to move `validate-ci-baseline` into its own small workflow? A PR would pick up the context in seconds, and the heavy matrix would run when someone actually pushes to it. That would also drop the rebase requirement for most PRs: `pull_request` here defaults to `[opened, synchronize, reopened]`, so a close/reopen re-reports on the same head SHA, and with `strict: false` and GHA building `refs/pull/N/merge` against current master, a rebase adds no signal over that except where the branch genuinely conflicts. -- 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]
