I did some quick calculations, and we can't afford the CI with our existing infra.
Per ASF policy (https://infra.apache.org/github-actions-policy.html), the maximum weekly runner minutes we have is 250k. That's 1m per month, and last month, we hit almost the exact number - 1,082,721 minutes. Our current CI consists of a few components (all numbers are per month): * each commits on master branch - ~280k * 4.1 scheduled run - ~200k * 4.0 scheduled run - ~200k * 3.5 scheduled run - negligible because we don't run many tests * master scheduled run ~ 300k With the new release cadence, even if we only do scheduled run on 4.x (which we shouldn't because it's an active dev branch but that's another story), we need an extra 200k. With a 6-month maintenance window, we will always have at least 3 active maintained versions (including LTS) that require CI. If it's just 200k extra, maybe it's manageable. But I really believe we need tests for the 4.x branch - we should treat that branch more like master, than say 4.2. Even if we don't do pre-merge check on it, we should do post-merge check for every commit. Daily check on an active dev branch sounds a bit too risky to me. That would be another 300k. This does not include the discussion about any pre-merge check for 4.x, which we should actually think about in the future. So the question is - how do we deal with that? The solutions I can think of are * Get some self-host runners and increase our CI capability limited by ASF policy * Optimize our CIs and tests so it takes less time to run * Reduce the coverage of our tests so we can at least test all branches Any idea is welcome. Tian
