> On Oct 28, 2026, at 6:36 PM, Hyukjin Kwon <[email protected]> wrote: > > We're facing resource issues in CI. More than 50% is from the post builds.
Just to be clear, do you mean the builds of commits after they’ve landed on master? Also, do you have a rough analysis available anywhere to review? Someone from ASF Infra shared an analysis that seemed to indicate the biggest source of GitHub Actions usage was from our scheduled builds, not master. > I have an idea to leverage committers' fork when they merge, triggering a job > in committers fork repo. The capacity might be an issue. WDYT about it? I haven’t thought this through fully, but I feel like we should explore the idea of a custom merge queue <https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue>. We mark a PR as ready to merge, and an automated process tests it against the latest master (using the fork’s GHA budget) and merges it in automatically on success. If a PR fails the build, it gets removed from the queue. We already build PRs in the fork context; we just need to automate the process of testing against the latest master + merging it in. Backports + Jira management can continue to be driven manually by the merge script. Nick
