Repository navigation
[PILOT-00] Spike: build and test a sample task under gVisor offline #500
Description
Why
PILOT-06 (#493)'s execution checkers (image-builds, oracle-passes, noop-fails, tests-stable) must build a contributor-supplied Dockerfile and run its tests inside the PILOT-04 (#491) sandbox with networking off and no host Docker socket. This is the riskiest unknown on the pilot path, and its answer can change PILOT-04 (#491)'s runtime design. Prove or disprove it before PILOT-04 (#491)'s ADR is finalized.
Questions to answer
- Which builder works inside gVisor (
runsc) without privileges or the host socket: BuildKit rootless, kaniko, buildah, or other? Anyrunscflags/platform needed? - How are base images supplied offline: pre-pulled, digest-pinned local registry/cache mounted read-only? How does that interact with
canonical-base-image/pinned-from? - How do tests run against the built image: nested container in the same sandbox, a second sandbox, or rootfs unpack + direct execution?
- Realistic time, CPU, memory and disk per run for a typical Terminal-Bench-style task; what limits are safe?
- What happens on macOS
docker-devfallback? - Which failures are infrastructure (builder crash, cache miss) versus genuine work failures (Dockerfile error)?
Deliverable
A short written result in the issue (or a draft ADR section for PILOT-04 (#491)) with: chosen mechanism, a minimal reproducible script, measured numbers, and known limits. Throwaway code is fine; nothing merges to product paths.
Timebox: 2–3 days. If no mechanism works, report that so PILOT-04 (#491)/#493 can be redesigned (for example a separate dedicated build VM per run) before more depends on them.
Acceptance
- One sample task's image builds and its oracle tests run under gVisor with networking off and no host socket, or a documented reason why not.
- Measured resource and time numbers recorded.
- Recommendation linked from PILOT-04 ([PILOT-04] Register and execute external sandboxed checkers #491) and PILOT-06 ([PILOT-06] Coding-task execution and guide-compliance checkers #493).
Completed by PR #507, merged as 36e8a615f01801cecd6ccf83d7411235ab1cfa8f. The merged result records the reproducible Linux sample, measurements and qualified recommendation, already linked from PILOT-04 and PILOT-06. Representative workload sizing, hosted hardening and macOS validation remain with the owning implementation issues.
Activity
[-]Spike: build and test one sample coding task under gVisor, offline, without the host Docker socket[/-][+][PILOT-00] Spike: build and test a sample task under gVisor offline[/+]Abiorh001 commentedon Oct 8, 2026
Reviewed PILOT-00 result: draft PR #507 records the reproducible probe and decision input.
The included digest-pinned Alpine fixture built with maintained Kaniko inside
runscwith networking disabled, no host container socket, and a non-privileged container configuration. A second gVisor sandbox ran the oracle as UID 65532 with no capabilities and a read-only root. Final replay: build 16.420 s, oracle 3.226 s, 27,283,948-byte sampled peak memory, 35 PIDs, 3,638,784-byte output. Dockerfile exit 42 remained a work failure; cache miss, forced deadline, OOM, and output-disk exhaustion were distinct infrastructure candidates.Recommendation: PILOT-04 should use a trusted launcher to prepare a read-only platform-digest cache, run bounded Kaniko inside gVisor, hash/import the attempt output, and execute the oracle in a separate gVisor sandbox. The privileged, networkless outer DIND used by this development probe is only a runtime-registration harness; it is not proof of a privilege-free deployment.
Limits remain explicit: the fixture is tiny and does not establish typical Terminal-Bench sizing, hosted hardening, byte-reproducible output, or macOS/Apple Silicon behavior. Ordinary Docker Desktop is only a visible
docker-devfallback, not gVisor evidence. No issue is closed by this comment.