Build a Dockerfile on an explicitly selected Machine #802

Parent

Build runner spec (#798)

What to build

Implement a complete remote build-only path for a Dockerfile through the existing authenticated Ployz stream and the same execution-host routine. A client with no Docker daemon captures source, reaches one selected Machine, observes the attempt, and receives its remote image result. Railpack-specific product proof is separate, so it does not artificially block this transport slice.

Acceptance criteria

• Support an explicit remote Machine target on standalone build, resolving existing identity/Name Ambiguity rules and checking the actual BuildKit worker and image-store capability. Report the selected Machine. Missing, ambiguous, unreachable, or incompatible targets fail without silent fallback or resubmission. The optional target syntax requires '=' and must not consume a positional Service.
• Reach the shared host executor using the existing authenticated Ployz stream. The daemon owns local admission and resources; the host routine accepts only source, recipe, platforms, private values, and local policy, with no ComposeProject, Cluster selection, or Deploy knowledge. Keep BuildKit private and add no separate build server. Do not require a local Docker daemon, local BuildKit server, or local image inspection.
• Admit at most one active Build on the selected Machine, sharing exclusive ownership of its retained builder state. Reject a second attempt clearly in this first remote slice; the bounded-waiting-queue ticket replaces that temporary busy refusal. Do not upload source until admission. The thirty-minute active timeout covers upload, preparation, build, assembly/import as applicable, and cleanup.
• Stream captured source with bounded buffering and receiver-side path/link/framing/size validation; interrupted or malformed uploads cannot escape staging or become runnable partial inputs. Keep credentials separate from reusable source and metadata and do not read client paths or ambient project credentials on the remote host. Clean private attempt material when safe.
• Stream progress and return the exact image identity, actual platform coverage, tags, and selected Machine ID. Preserve typed validated/failed/unknown outcomes and distinguish the earliest proven failure stage. Keep the image remote; standalone build must not deploy or transfer it implicitly.
• Handle explicit cancellation, observed disconnect, timeout, and process failure by requesting bounded termination and cleanup. Report unknown when termination cannot be confirmed and hold conflicting builder/cache ownership until safe. Do not automatically resume, replay, or choose another Machine. Preserve completed-versus-unattempted work evidence.
• Use rung-1 trust-boundary validation and rung-2 owned-transport tests, plus rung-3 actual CLI parsing and a sentinel proving no local Docker access. Register a rung-4 build on a real selected Machine from a Docker-less client, then execute the image there; cover a competing request, interrupted upload, active cancellation, and unknown termination. Do not claim that mocks prove a remote image.

Blocked by

• #800 — Capture portable build source and private variables