We can't fix the ASF-wide queue, but we can ask much less of it. Our 11 hand-made test jobs cost too much and are hard to maintain. Together with 4 static-analysis and integration jobs, they took about 230 runner-minutes for one commit of https://github.com/apache/calcite/pull/5350, and the Linux jobs waited 2 hours in the queue.
Each job is a 30-line copy of another with one or two values changed, and the set has drifted. It tests JDK 24, an outdated non-LTS release, and never JDK 25 or 27. It tests two Guava versions, only the Zulu JDK, and only an English locale. Two steps: 1. https://github.com/apache/calcite/pull/5352 stops running CI twice when a PR comes from a branch in apache/calcite. 2. Replace the 11 test jobs with 5–6 jobs generated by https://github.com/vlsi/github-actions-random-matrix, which I proposed in 2021 [1]. A short script lists the axes (OS, LTS JDKs and the latest GA, Guava versions from 21.0 to the latest, time zone, locale, JDK vendor, `-XX:hashCode=2`) and the rows every run must have (Windows, JDK 8, the latest JDK, the oldest and the latest Guava). The library fills the remaining jobs with value pairs no row covers yet. What we get: - Fewer resources: about 110–125 runner-minutes per commit instead of 230. - About the same coverage per run: 5–6 random jobs cover about as many value pairs as today's 11, and more once locale, JDK vendor, and hash code count. - Much better coverage over time: every commit to `main` draws new rows, so a week of commits covers about 90% of the pairs. Today's jobs cover the same third of them on every commit. - Easy maintenance: moving to JDK 28 or adding a Guava version is a one-line edit. - Reproducible failures: each job name lists its parameters, a PR keeps the same rows across pushes, and the printed seed replays a run locally. Apache JMeter, pgjdbc, and TestNG already use it. I maintain the library and can prepare the PR if there are no objections. [1] https://lists.apache.org/thread.html/gw7klmm4000y6lnbh3yjqj1g1ljswgt5 Vladimir
