yihua opened a new issue, #19524: URL: https://github.com/apache/hudi/issues/19524
## Context ASF Infra disabled GitHub Actions on apache/hudi on 2026-08-04 over how much runner time our CI consumes (discussion #19515). #19523 resets `required_status_checks` and #19514 cuts the matrix to one configuration per area so we can merge again. Measured on master before that trim: 71 checks per push, peak 63 concurrent runners, roughly 46 runner-hours per push. After it: 19 checks, peak around 16, roughly 10 runner-hours. The [ASF GitHub Actions policy](https://infra.apache.org/github-actions-policy.html) sets concurrency MUST be at most 20, SHOULD be at most 15, and caps a project at 4,200 runner-hours per week. The trim is an interim measure. It buys headroom by deleting coverage, and the lanes it takes out are commented in place and marked `[CI-TRIM]` rather than restored. This issue tracks getting back to CI we actually want: inside the ASF budget, fast enough that contributors do not wait on it, and covering the versions we claim to support. The existing CI tickets in the tracker are all migrated JIRAs from the Azure Pipelines era (#14887, #15002, #16341, #16170, #15749) and none of them describe this. ## Goals 1. Stay within the ASF policy, including the SHOULD target of at most 15 concurrent runners, without further coverage loss. 2. Cut wall-clock time to first signal and to a full green run, so a PR is not gated on a 70-minute critical path. 3. Restore and then broaden real coverage, so that green means the change works on the versions we ship. ## Workstream 1: runner budget and concurrency - Reach the SHOULD target of at most 15 concurrent runners. `max-parallel` does not help here: it caps matrix entries within a job, and every surviving job has exactly one entry, so peak concurrency equals the job count. Merging `test-flink-1` with `test-flink-2`, and the two bundle-validation jobs, gets there and is free in wall clock, since both merged jobs (69 min and 25 min measured) stay inside the critical path set by `test-spark-java17-java-tests-part1`. - Track weekly runner-hour usage against the 4,200 cap so we notice a regression before Infra does. - Make path filtering do more work. The `changes` job already skips irrelevant runs; extend it so a docs-only or single-engine change does not pay for the full matrix. - Reuse build output across jobs instead of rebuilding the world per lane (artifact upload/download or a shared build stage), which is where much of the runner time goes. ## Workstream 2: wall clock - The critical path is `test-spark-java17-java-tests-part1` at roughly 70 minutes. Rebalance the Spark part1/part2/part3 splits by measured duration rather than by module boundaries, and re-measure after every change to what those jobs run. - Report the slowest tests per job so the long tail is visible and can be fixed or moved off the PR path. - Cache Maven dependencies properly across jobs and runs (#15749 has a stale attempt at this). - Give contributors early signal: run the cheap validations and a fast compile before the long test jobs, so an obviously broken PR fails in minutes. - Consider moving the heaviest suites off per-PR runs to a scheduled or on-demand run, once per-version coverage is restored. ## Workstream 3: test coverage - Restore per-version Spark coverage. #19082 runs a curated core suite on every Spark version and reserves the full suites for the latest 3.x and 4.x, which is broader than the pre-trim matrix at a fraction of the cost. - Nothing currently compiles the Flink 1.18 through 2.0 datasource modules. A change to shared code that updates only the surviving lane can break them on master with every check green. A cheap compile-only lane per version would close this. - Bundle validation currently covers the Spark bundles only. The Flink, Kafka Connect and metaserver bundles are uncovered, as is the Presto bundle (#19468). - Restore the `[CI-TRIM]` lanes selectively as budget allows, preferring cheap compile or smoke coverage over full suites for the older versions. - Keep flaky tests from consuming the budget twice: a retried job doubles its runner cost. Quarantining and fixing the known flaky tests is part of this, not a separate concern. ## Cleanup - Delete `validate-ci-baseline` and its job once no pre-trim PR is open. It exists only so a PR holding green checks from the old matrix cannot merge on them. - Keep `required_status_checks` free of per-job contexts. Listing them is what made every matrix change a two-sided edit, and a context left without a job to report it blocks merges indefinitely. ## Related - #19514, #19523, #19082 - Discussion #19515 - Migrated JIRAs, kept for history: #14887, #15002, #16341, #16170, #15749, #16476 -- 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]
