SubmitQueue¶
A high-performance speculative submission queue that keeps your trunk consistently green at scale.
SubmitQueue does not validate changes one at a time. It speculatively rebases and validates many changes in parallel against predicted future states of HEAD. Changes whose validations pass land automatically. When a validation fails, SubmitQueue isolates the offending change and retries the rest, with no human involved. It is designed for large monorepos and fast-moving teams, where concurrent changes can introduce subtle conflicts and destabilize builds.
Why SubmitQueue¶
-
Speculative validation
SubmitQueue builds a tree of possible future HEADs and validates the paths most likely to land, in parallel.
-
Isolates failures
A failing change is isolated and rejected while the rest of its batch carries on to land.
-
Pluggable extensions
Build runners, change providers, storage, queues and scorers are vendor-agnostic interfaces with swappable implementations.
-
Durable, queue-driven pipeline
Every stage is an idempotent consumer on an at-least-once message queue, with optimistic locking and no distributed transactions.
Components¶
-
SubmitQueue
The gateway and orchestrator that accept, batch, speculate on, build and land changes.
-
Runway
The landing service. It owns VCS operations, conflict checks and merges, on SubmitQueue's behalf.
-
Stovepipe
The post-land pipeline. It validates landed commits and tracks the last green revision.
Try it in a minute¶
You need only Docker. No repository, account or token is required.
make local-submitqueue-start # Gateway + Orchestrator + Runway + MySQL
make demo-requests # create changes, enqueue them, watch them land
make local-submitqueue-stop
The Quickstart goes from a fake provider to a local git repository to real GitHub pull requests. Questions? Join the Slack community.