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.
Put traffic through the queue and watch it land. Requires Docker and Docker Compose, and nothing else — 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-stopPROVIDER 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.
| 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.