SubmitQueue is a high-performance speculative submission queue that keeps your trunk consistently green at scale. Rather than validating changes one at a time, SubmitQueue speculatively rebases and validates multiple changes in parallel against predicted future states of HEAD. When validations pass, changes land automatically. When they fail, SubmitQueue isolates the offending change and retries the rest — all without human intervention.
Designed for large monorepos and fast-moving teams where concurrent changes can introduce subtle conflicts and destabilize builds.
Documentation: uber.github.io/submitqueue has guides, design docs (RFCs) and search.
Cross-domain Go code (errors, metrics, consumer framework, HTTP helpers, shared entities, shared extension contracts) lives under platform/. Each product domain has its own tree (submitqueue/, stovepipe/, …). Multi-service domains may split into gateway/ and orchestrator/; single-service domains keep controllers directly under the domain root. Stovepipe currently exposes ingestion behavior and runs its own queue pipeline. See AGENTS.md for conventions and import paths.
Put traffic through the queue and watch it land. Requires Docker; Bazel supplies Docker Compose. No repository, no account, no token.
# Start the full stack (Gateway + Orchestrator + Runway + MySQL) make local-submitqueue-start # Create changes, enqueue each as it is created, and watch them settle. # It finds the running stack's port and provider itself — nothing to copy. make demo-requests # Stop services make local-submitqueue-stop
PROVIDER decides where changes come from and what landing them does, and it is the only thing that changes between them:
PROVIDER |
A change is | Landing it | Needs |
|---|---|---|---|
fake (default) |
a URI, and nothing else | reports success without touching a repository | nothing |
git |
a branch in a bare repository on disk | a real fetch, cherry-pick and push | nothing |
github |
a real pull request | a real push to a real repository | a repository and a token |
The queue's own logic is real in all three: validation, batching, conflict analysis, speculation, and a request log recording the full trail from accepted to landed. PROVIDER=git make local-submitqueue-start is the first rung where a commit actually reaches a branch, and it still needs no credential.
Quickstart walks all three rungs — proving a change landed with git log, making one fail on demand, and what a live provider needs. See service/README.md for running individual services and clients.
The documentation site at uber.github.io/submitqueue renders everything under doc/. The same documents, in the repository:
| Document | Description |
|---|---|
| Quickstart | Run the stack and land changes — fake, local git, or GitHub |
| Development Setup | Prerequisites, build, environment, IDE setup |
| Contributing | How to contribute, workflow, guidelines |
| Testing Guide | Unit, integration, and E2E testing patterns |
| Architecture Guide | Project layout, patterns, conventions |
| Examples | Running services, clients, API reference |
| RFCs | Design documents and proposals |
SubmitQueue is under active development. We welcome contributions and feedback.
Join us on Slack: submitqueue.slack.com — questions, design discussions, and help getting started.
See CONTRIBUTING.md for how to get started.
Licensed under the Apache License 2.0.