codeSplitters CI: a build and test runner on the desktop and in a container #463

Part of dogfooding: codeSplitters hosts codeSplitters (and RustyBuns), with GitHub as the backup. Sibling issues: the desktop as the primary git store (#464), and the integration that ties checks to pushes, branches and GitHub (#465).

What

codeSplitters runs a repo's build and tests itself: on the desktop (a Bun server on your own machine, using your own toolchain) or on the edge in a container. GitHub Actions stops being the only CI.

Pieces that already exist

• src/deps.ts already runs installs and tests in a throwaway clone, a temp dir on the desktop or a container on Cloudflare.
• src/cuts.ts runs bun test and reads its JUnit report.
• src/deploy-runner.ts and deploy-sandbox/ already have a per-repo Durable Object, a container and streamed output under an alarm's time budget. The CI runner needs the same shape without deploy keys, so it gets its own binding, as agents do.

Scope

1. What to run. Use a repo's codesplitters.ci config when it has one. Without one, use its package.json test / typecheck scripts. For a monorepo, use per-app commands (RustyBuns: scripts/ci-apps.ts already lists them, and only the apps a change touched run). Leave parsing .github/workflows/*.yml for later.
2. The desktop runner. Spawn the commands with Bun.spawn in a checkout from codeSplitters desktop: the primary git store, local out and GitHub in #464, streaming output into the check run's log. Install scripts follow the deps.ts rules.
3. The container runner. A CiRunner DO plus an image (git + bun). One run at a time per repo, a later commit cancels a queued run, and it holds no secrets.
4. Limits. Container runs count against src/limits.ts (see codeSplitters limits: rate-limit preview and deploy runs #238). The desktop is free.

Done when

• A commit to a desktop repo can produce passed / failed check runs with logs for codeSplitters' own bun test test.
• The same run can happen in a container on a local dev Worker.
• Tests cover choosing what to run and the runner state machine (no real containers in tests).

The shared contract (all three issues build against this)

A check run is one record: { id, owner, repo, ref (branch or main), sha, name, runner: "desktop" | "container" | "github", status: queued | running | passed | failed | cancelled, started_at, finished_at, log (streamed), junit? }. It lives in D1 (a check_runs table) and comes in over GET /api/repos/:o/:r/checks?ref= and POST /api/repos/:o/:r/checks/:id/cancel. The runner (#463) writes them, the local store (#464) gives it a real checkout to run in, and the integration (#465) decides when to start them, shows them and gates merges on them. Whichever issue lands first adds the table; the others rebase onto it.