Skip to content

codeSplitter: flag checks/deploys that need Docker or Rust up front, with one-click Run on desktop #817

Closed as not planned

Description

@QuinnsCode

Problem

The hosted containers can't run Docker, and the check image has no Rust (deploy-sandbox/ci.Dockerfile). How codeSplitter handles that today:

  • Deploys: a box whose native/ crates need another arch is refused, but only once the run reaches the deploy step (src/preview.ts:217), after the clone and install.
  • Checks: a check that needs Docker or cargo starts in the container and fails partway through with a raw command not found. The only guidance is the generic "Run it on the desktop app or a runner of your own" when a run is cancelled (src/ci-runner.ts:219).

The user finds out late, from a log, and has to work out where to go next.

What good looks like

Know before running. When a check or deploy is queued, a cheap capability scan works out what the run needs: native/Cargo.toml and the box's arch, docker/cargo/rustc in the check's command or in package.json scripts it calls, and a Dockerfile it builds. It compares that with what the target container image provides. The image's capability list lives next to its binding in rustybuns.config.ts, so the scan and the image can't drift apart.

Say it in the UI, early and visually (in codeSplitter's style: GitHub black-and-white with orange, icons rather than wrapping labels):

  • On the check or deploy row, before it starts, show a small icon chip (🐳 or the Rust gear) with a tooltip like "Needs Docker. Hosted checks don't have it."
  • Replace the Run button with a split button:
    • Run on desktop (default when the desktop app is connected) queues the run with runner = 'desktop', which ci-runner.ts already drains.
    • Run on my runner shows the scripts/runner.ts one-liner with a copy button, filled in for this repo.
    • Run hosted anyway stays available, dimmed, for when the scan is wrong.
  • If nothing can run it (no desktop connected, no runner registered), give a short empty state with the two ways to get one, not a failed run.

When it still fails in the container, recognize the missing-tool signature (docker: not found, cargo: not found, a refused arm64 crate build). Mark the run Needs desktop, not failed, with the same one-click handoff, so the PR's status doesn't go red for an infrastructure reason.

Out of scope

  • Docker-in-Docker or a privileged hosted runner. That's a security change for the hosted images. If wanted, file it separately.

Acceptance

  • A repo whose check runs cargo test shows the Rust chip and defaults to "Run on desktop" before anything starts.
  • An arm64 box deploy is flagged at queue time, not at the deploy step.
  • A container run that hits docker: not found ends as "Needs desktop" with the handoff, and the commit status isn't a failure.
  • Tests cover the capability scan and the missing-tool classifier.

Activity

  1. added
    accessibilityBarrier affecting people with disabilities
    enhancementNew feature or request
    and removed
    accessibilityBarrier affecting people with disabilities
    on Oct 12, 2026
  2. QuinnsCode commented on Oct 12, 2026

    @QuinnsCode
    OwnerAuthor

    Folded into #818, which now holds this spec in full along with the other container and Docker work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions