The merge queue is in effect and seems to be working well so far. I have another PR open to move the Spark Hive tests to the merge queue next, as they use a lot of CI resources and rarely catch regressions.
Per the new CI section in the contributor guide, changes to the CI setup should be announced on the mailing list, so I am sharing this for awareness. Please comment on the PR if you have any feedback. https://github.com/apache/datafusion-comet/pull/5871 On Fri, Sep 11, 2026 at 7:29 AM Andy Grove <[email protected]> wrote: > > Hi all, > > We are planning to enable GitHub's merge queue on the Comet main branch to > reduce CI resource usage. This note explains what changes for contributors > and committers, and gives everyone a chance to raise concerns before it is > turned on. The tracking issue is > https://github.com/apache/datafusion-comet/issues/5838. > > Why > > CI load on pull requests is dominated by suites that do not need to be green > until merge time. Today Spark 3.5 SQL tests run on every push to every PR, and > Spark 3.4/4.0 and the older Iceberg suites run again after every merge. With a > merge queue, GitHub builds the exact tree that will land (up to five PRs > batched together) and runs CI against that once. An iterating PR runs a > smaller set, and nothing runs twice. > > What changes > > 1. Two CI tiers, decided by which event triggered the run. > > PR tier (every push to a PR): Linux and macOS build and unit tests, > benchmark check, Spark 4.1 SQL tests, Iceberg 1.11. > > Queue tier (when a PR is queued to merge): everything above, plus Spark > 3.4, 3.5 and 4.0 SQL tests and Iceberg 1.8, 1.9 and 1.10. > > Spark 3.5 is the one contributors will notice: it currently runs on every > PR push and becomes queue-only. If you need it on a PR, add the > run-spark-3.5-tests label (run-spark-3.4-tests, run-spark-4.0-tests and > run-iceberg-tests work the same way). > > 2. How merging works. Instead of "Squash and merge", committers click "Merge > when ready". GitHub adds the PR to the queue, runs the queue tier against > the merge result, and merges automatically when the single required check > ("Required Checks") is green. A PR can be queued before its own PR-tier > checks have finished. > > 3. No more post-merge test runs. Because the queue already tested the tree > that landed, the heavy jobs no longer run on push to main. Only the docs > site deploy does. > > Impact on open PRs > > The required check is new. Any open PR whose last CI run happened before > https://github.com/apache/datafusion-comet/pull/5842 merged will not have a > "Required Checks" result and cannot be queued until it gets a fresh CI run. > Pushing a new commit or rebasing is enough. > > Flaky tests > > Once the older Spark and Iceberg suites gate the queue, a flaky test in any of > them blocks everyone's merges rather than leaving main red for one commit. > That raises the bar on flakiness. Please treat any flake seen in the queue > tier as a bug to fix or quarantine promptly, and file an issue when you hit > one. > > Rollout > > Step 1, https://github.com/apache/datafusion-comet/pull/5842, adds the > "Required Checks" aggregator job with nothing requiring it yet, so we can > watch it report correctly on real PRs first. Step 2, > https://github.com/apache/datafusion-comet/pull/5843, declares it as the > required status check and turns the queue on via a ruleset in .asf.yaml. The > queue parameters (batch up to 5 PRs, 2 groups in flight, no minimum wait, 5 > hour check timeout) are easy to tune afterwards. ASF Infra (apache/root) is a > bypass actor so a wedged queue can always be recovered. > > If there are no objections we will merge step 1 shortly and step 2 once it > has reported cleanly on a few PRs. > > Thanks, > Andy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
