Queue distribution

Most CI parallelism splits the suite before the run starts, by file and by historical timing. The split can’t know how long each file will take today, so one node usually draws the slowest files and the build waits for it while the others sit idle.

Selective doesn’t pre-split. Every node that connects with the same run identifiers joins one queue. Selective hands tests to whichever node asks next, and a node asks again as soon as it finishes what it was given. Total runtime is decided by the total work divided by the number of nodes, not by the unluckiest node’s share.

What this means in practice

• Add nodes by running the same command on more of them. No partitioning config to keep in sync.
• Nodes can join late or drop out. A node that starts slowly just takes fewer tests. Tests that were in flight on a node that disappears are handed to another.
• The run ends when the queue is empty. Each node’s command exits once there is nothing left, so a node never waits on another’s straggler.
• Reruns are cheap. Retrying a build from the CI provider reconnects the nodes to the same run and continues from what is already known.

Ordering

Within the queue, Selective orders tests so the ones most likely to fail run first: tests that exercise files in the change, then tests for files that have historically changed alongside them, then everything else. See Test ordering.