Loading navigation…
User
How a change moves from pull request to production, and why each stage of automation exists.
Every pull request in the monorepo — including changes to Dispatch (turbo/apps/dispatch) — passes through three stages of automation before reaching production. This section documents the GitHub Actions workflows that make up each stage: what runs, when it runs, and why it exists. The goal is to make it obvious which checks are blocking your merge versus advisory, and where to look when a check fails.
For the full visual map of this pipeline (including all 31 deployable apps and every environment), see the cicd-pipeline diagram in docs/diagrams (source: docs/diagrams/data/cicd-pipeline.mmd). This section is the prose companion to that diagram, focused specifically on the checks a Dispatch PR encounters.
trunk. Some checks are required (block the merge), others are advisory (report information but don't block).build.yaml ("Docker Build") builds and pushes a live-dispatch image to ECR for that commit. Playwright integration/E2E tests wait for this image rather than rebuilding it themselves.trunk auto-deploys to the dev environment. Production deploys happen on an hourly schedule (driven by .github/deployment-schedule.yaml) or manually via workflow_dispatch, and require an explicit approval gate.None of these workflows are here for their own sake — each one encodes a specific incident, review gap, or manual step the team was tired of doing by hand:
merge-gatekeeper is the single point that decides "is this PR actually mergeable," so branch protection only needs to require one check instead of enumerating every CI job (and needing updates every time a job is renamed or added).check-halted is an org-wide kill switch — when there's an active incident, one LaunchDarkly flag flip stops all merges to trunk without anyone touching branch protection rules or individual PRs.check-eslint-suppressions and check-high-risk-changes exist because some categories of change (growing lint-suppression debt, high-risk backend changes) are easy to approve by accident in a normal review pass — they force a specific, accountable sign-off.dispatch-ci exist because frontend regressions (bundle bloat, type errors, coverage drops) are cheap to catch in CI and expensive to catch after a Dispatch release ships.Each entry lists its trigger conditions and current blocking status as of when this page was last updated. The single source of truth for what's currently blocking is the --ignored list in merge-gatekeeper.yaml — anything not on that list is a required check. If this page and that file disagree, trust the file and update this page.