SubmitQueue is a high-performance speculative merge 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.
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/, …) and grows into gateway/, orchestrator/, entity/, extension/, and domain-local core/ — though a domain may start smaller (Stovepipe is currently a single Ping-only service with just controller/). See CLAUDE.md for conventions and import paths.
Land a change and watch it reach landed. Requires Docker and Docker Compose, and nothing else — no repository, no account, no token. See Development Setup for full prerequisites.
# Start the full stack (Gateway + Orchestrator + Runway + MySQL)
make local-submitqueue-start
# Compose publishes a random host port; the line above prints it, as does this
make local-submitqueue-ps
export GATEWAY_ADDR=localhost:<gateway port>
# Submit a change, and follow the receipt it returns
make land QUEUE=test-queue \
URI='git://git.example.com/demo/refs%2Fheads%2Ffeature-a/1111111111111111111111111111111111111111'
make land-status QUEUE=test-queue SQID=test-queue/1
# Stop services
make local-stopEvery integration at the edges is faked — the change provider, CI, and the merge itself — so the run is free and finishes in seconds. The queue's own logic is real: validation, batching, conflict analysis, and speculation all run, and the request log records the full trail from accepted to landed. Nothing is pushed to any repository.
Quickstart explains the change URI, how to make a change fail on demand, and what this does and does not prove. From there, make e2e-git-test adds a real git merge (still no credentials), and PROVIDER-E2E.md adds a live provider. See service/README.md for running individual services and clients.
| Document | Description |
|---|---|
| Quickstart | Land a change locally with no credentials |
| Development Setup | Prerequisites, build, environment, IDE setup |
| Contributing | How to contribute, workflow, guidelines |
| Testing Guide | Unit, integration, and E2E testing patterns |
| Landing real changes | Running the pipeline against a live provider |
| 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.