CI/CD Pipelines

This page is the entry point for CI/CD. The day-to-day operational detail now lives in the dedicated DevOps pages below so the docs stay current as workflows change.

​

Read Next

• DevOps & Deployment Overview
• Environments & Release Flow
• Web Docker Deployment
• GitHub Actions Runbook
• Secrets & Configuration

​

Current CI/CD Shape

Tuturuuu currently automates:

• Vercel preview deployments for non-production branches
• Vercel production deployments from the production branch
• Independent Vercel preview and production deployments for satellite apps such as apps/cms
• Affected-app gating for Vercel deployments before dependency install, build, or deploy work
• Supabase staging migrations driven from main and production migrations driven from production
• Docker parity and image validation for the self-hosted web runtime
• Modal deployment for apps/discord
• Mobile build artifact generation
• Package publishing to npm
• Quality, lint, type, test, and security checks

​

Important Repo Conventions

• For most authored changes, run the applicable check, lint, test, and build workflows in CI and verify their results on the exact commit. Focused local checks help find problems quickly but do not replace that CI evidence. If a workflow queue is demonstrably stuck, record the pending jobs and local results; resume the exact-commit CI checks before claiming release readiness.
• ci-check.yml reads tuturuuu.ts and can disable an individual workflow centrally.
• Vercel workflows use tuturuuu.ts app metadata and workspace workspace:* dependency closures to run only affected app deploys.
• bun.lock changes run all Vercel app deploys because lockfile ownership is ambiguous without a source or manifest path.
• Manual workflow_dispatch runs enabled workflows even when changed paths would otherwise be unaffected.
• Production Vercel workflows cancel superseded per-app runs only for newer production pushes. A main commit or manual recovery run never cancels an active production deployment.
• The external-app internal-package build uses the same cancel-superseded policy, so rapid pushes cannot finish as green no-op builds.
• Database migrations are not treated the same as app deploys; staging and production each have explicit prerequisite logic, with staging now sourced from main.
• Docker setup and image-build CI (docker-setup-check.yaml) are disabled, including manual dispatch, until explicitly resumed.

​

Inline Type Check preflight regressions

type-check.yaml runs node --test --test-reporter=tap scripts/ci/type-check-inline-workflow.test.js on its exact checkout with Node 24, after the existing Setup Bun step and before dependency installation. Bun is required by the workflow YAML test helper; these 21 regression cases need no workspace dependency installation. The step uses the existing configuration and release-relevance gates. A skipped step is not test evidence. Before merging a preflight fixture change, verify the exact-head hosted step succeeded and its TAP summary reports 21 tests, 21 passes, and zero failures, cancellations, skips, or todos.

​

Worker validation caching

Cron Control and Devbox Control run package build, test and type-check tasks through the existing Turbo remote-cache action with explicit workspace filters. Meet Realtime uses the same action for build and type-check. Worker builds restore the declared dist/** outputs before emitted-artifact verification. Cron Control and Devbox Control generate binding types before cached type checks because the generated .d.ts file is not a declared type-check output. Lint, source and emitted runtime checks, SQLite and Durable Object verification, and deploy dry-runs still run directly. Remote credentials remain step-scoped and are supplied only to trusted main or production runs, never untrusted PRs.

​

Hosted root script qualification

The Test workflow runs the complete selection exported by scripts/run-script-tests.js in a separate Root script tests (24) job on the exact checkout. Node 24 runs it with two test-file workers and the TAP reporter; the existing paused-runtime discovery policy remains unchanged. No shell glob or subset replaces the canonical selection. The job installs the frozen dependencies with the existing Bun setup, verifies Ruby and @playwright/test resolution, and exposes the owning Web dependency location through NODE_PATH. It needs no application secrets, browser install, workspace build, deployment, or production action. The unit-test aggregation requires successful package shards or verified duplicate package evidence, and always requires the fresh root script job to succeed when checks are relevant. Configuration and release-relevance gates still apply. The root script job does not reuse the package-shard duplicate-validation result. A skipped job or green package shards do not prove root script qualification: require the exact-head job, prerequisite results, complete discovery count, and full TAP summary. Historical failures remain unresolved until their actual cases pass on the qualified source; do not infer a fix from a different branch’s test bytes.

​

Hosted Rust source qualification

On fix/release-5795-reconciliation and fix/main-production-reconciliation-20261012, the existing Test workflow runs Rust source qualification (1.95) after the shared configuration and release relevance gates. The read-only job checks out the exact workflow commit, records its SHA and Cargo manifest/lock hashes, and uses pinned Rust 1.95.0 with two Cargo build workers. It runs formatting, warning-denying native Clippy, all native library tests with two test threads, and the wasm Worker target check against the locked dependency graph. It needs no application secrets or deployment action. The stable Unit Tests (24) aggregate requires this fresh job to succeed on those branches, including when verified package duplicate evidence skips shards. A skipped Rust job or successful root script tests do not qualify Rust: require the exact-head job and its complete Cargo results. Other branches retain their existing package/root gates. The standalone Rust workflows, TanStack migration, and backend deployment remain paused; the backend is a future migration target, and Web continues to serve the live API.

​

Cross-app users-core regression tests

The canonical approval regressions live outside the package source tree:

• packages/users-core/tests/approvals/get-tenant-boundary.test.ts
• packages/users-core/tests/approvals/review-reads-tenant-boundary.test.ts

The source type-check project keeps rootDir: "src". Vitest discovers the cross-app tests separately through packages/users-core/vitest.config.ts; relocating these tests does not expand the package’s source compiler boundary. That config maps the Web-specific imports @/lib/post-email-queue and @/features/reports/report-limits to their exact apps/web/src files before its default @ alias, which still points to packages/users-core/src. The exact @tuturuuu/satellite/auth mapping points to packages/satellite/src/auth.ts; it keeps the satellite namespace separate from the package-local @ imports. Run selected tests from packages/users-core with that canonical config and the receiver’s qualified dependencies. For a source TS6059 error, check that the cross-app test is outside src. For a Vitest module-resolution failure, check the owning cwd, specific alias destination, and installed dependency closure before changing compiler roots or alias scope. A config/source handoff or historical donor test and type results do not prove the current receiver’s test, type, CI, or runtime outcome.

​

When To Use This Page

Use this page for orientation. Use the DevOps pages for the runbook you actually need while operating the system.

​

Learn preview build validation

The trusted manual vercel-preview-learn.yaml workflow builds the checked-out preview_ref with a 35-minute timeout and the existing two-task Turbo limit. It records a build marker using git rev-parse HEAD, rather than the main workflow dispatch SHA. It does not deploy the artifacts. Learn build markers cannot advance the successful deployment baseline; existing Platform marker compatibility remains unchanged. A successful build proves compilation, while actual-device validation and deployment are separate gates. Focused checks: node --test scripts/ci/learn-preview-build.test.js scripts/ci/github-deployment-markers.test.js scripts/ci/release-workflows.test.js.

​

Generated release inventory

Release Please owns platform and independent package version changes. Release normalization derives only apps/docs/reference/repository/versions.mdx using the complete documentation inventory generator. Other stale inventory pages fail the job; this phase does not repair unrelated source or navigation changes. Before updating the generated PR, the workflow captures its previous immutable head. A retained versions page must match either the production page, the new complete projection, or the independently verified projection at that captured head. Changed generator/configuration sources and unproven docs bytes fail closed. The amended generated commit keeps its release annotations and is pushed using its exact head lease. Concurrent updates reject that push. Auto-approval verifies the final immutable page before rechecking the PR head and base. bun git-release-please also regenerates this page after resolving the platform version during integration and before validation or commit. Run node scripts/ci/release-docs-inventory.js --verify BASE HEAD to verify immutable release output. This is derived source evidence, not a publication or deployment receipt; failed release PR checks continue to block auto-integration.