GitHub user wombatu-kun added a comment to the discussion: [ACTION REQUIRED from contributors] Reducing our GitHub Actions usage: please rebase your open PRs
A few measurements, so the follow-ups here can be argued against numbers rather than intuition. Method: sum `completed_at - started_at` over non-skipped jobs, since `billable` comes back empty for public repos. A full `Java CI` run is 69 jobs, 67 of them concurrent, and 2,610 runner-minutes (43.5 h). At 255 runs in the week of Jul 27 that is ~7,200 runner-hours against the 4,200 h weekly limit, and the Spark datasource jobs are 78% of it. Everything outside `bot.yml` is rounding error. Two things that outlive the current trim: - Concurrency is a separate limit, MUST 20 and SHOULD 15, and nothing tracks it today. #19514 lands at 17 job instances, already above the SHOULD, and #19082 adds a 7-entry matrix on top of the surviving jobs, which puts us back over the MUST. Worth pinning with an explicit `strategy.max-parallel` rather than leaving it to the job count. - Nothing stops the matrix from regrowing. It went from 55 jobs and 1,845 min on Jun 4 to 69 jobs and 2,610 min on Aug 4, +41% in two months, almost entirely from added Spark versions; we carry 6 Spark and 5 Flink profiles today. #19082 tiers the versions we have now, but nothing in it says what happens when the next minor lands. Should the tiering carry a stated cap, say full suites on one 3.x and one 4.x only, so a new Spark minor adds a core lane instead of a full one? On the rebase ask I left a comment on #19514 instead, since it turns on that diff. GitHub link: https://github.com/apache/hudi/discussions/19515#discussioncomment-17900905 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
