Omar SobhandClaude Opus 5
53da4d7e6d
`clawmates-runtime` shipped with `gcc` and `make` but no `cmake`, no `g++` and no `python3-dev`. Measured on clawhdf5, three probes: no cmake → "is `cmake` not installed?" exit 101 after 13s no python3-dev → "cannot find -lpython3.11" exit 101 at link with both → cargo test PASSES exit 0 after 69s This is not only the delivery gate. The AGENTS run in this image, so a coding phase was writing Rust it had no way to compile or test — which reframes the last run's 11 agent commits as unverifiable by construction. `images/agent-toolchain/Dockerfile` (the microVM path) has had `cmake build-essential` all along, and its own header warns about precisely this: "if `cargo` is present in one image and absent in another, the same mission passes or fails depending on which backend it landed on, and nothing says why." Both images now install the same set — it was missing `python3-dev` too. `images/runtime-toolchain.Dockerfile` is a thin local overlay so the laptop can run today without recompiling zeroclaw from the fork; it is meant to be deleted once a runtime image built from the corrected deploy/ Dockerfile is published. Also: a build failure is no longer reported as a red suite. Both are cargo exit 101, and `verify_tests` mapped every non-zero to `Failed(code)` — so a missing toolchain was recorded as the USER's tests failing. It now returns `CouldNotRun` with the reason when the output shows a compile or link failure. Deliberately narrow: a failing `assert!` still reads as red, because letting broken code past `on_green_tests` is the expensive direction to be wrong in. Both directions are pinned by tests built from today's two real samples. And the coding phase finally has a loop: `research_and_code.toml` declared `loop = "until_no_more_int_items"`, which `phase_config.rs` lists as DECLARED_BUT_UNREAD. Iteration is driven by `max_iterations` + `done_when`, and with `max_iterations = 1` and no `done_when` the phase ran ONCE and was never judged — reporting `completed` whatever it produced. Now 3 passes against a stated goal, wording per the measured rule (say what the tree must CONTAIN). Co-Authored-By: Claude Opus 5 <[email protected]>
34 lines
1.5 KiB
Docker
34 lines
1.5 KiB
Docker
# A thin overlay that adds the C/C++ build toolchain to an already-built
|
|
# runtime image.
|
|
#
|
|
# The durable fix lives in `deploy/clawmates-runtime/Dockerfile`, which now
|
|
# installs `cmake build-essential` in its runtime stage. But that Dockerfile
|
|
# also COMPILES zeroclaw from our fork in an earlier stage — a long build that
|
|
# needs credentials for git.redclaw.dev — so rebuilding it just to add two apt
|
|
# packages is the wrong trade on a laptop.
|
|
#
|
|
# This layers those packages onto the existing image instead, which is exact:
|
|
# the same apt, the same distro, on top of the same base. Build and point the
|
|
# server at it with:
|
|
#
|
|
# docker build -f images/runtime-toolchain.Dockerfile \
|
|
# -t clawmates-runtime:toolchain images/
|
|
# CLAWMATES_RUNTIME_IMAGE=clawmates-runtime:toolchain
|
|
#
|
|
# Once a runtime image built from the corrected deploy/ Dockerfile is published,
|
|
# this file has no reason to exist — delete it rather than letting a second
|
|
# source of toolchain truth persist.
|
|
ARG BASE=clawmates-runtime:sync
|
|
FROM ${BASE}
|
|
|
|
# `cmake` and `g++` (via build-essential) plus `python3-dev` for pyo3 crates
|
|
# that link `-lpython3.11`. Missing them made `cargo test` on a repo whose
|
|
# deps drive a cmake build exit 101, which the delivery gate reads as a red
|
|
# suite rather than as "could not build".
|
|
RUN apt-get update \
|
|
&& apt-get install -y --no-install-recommends cmake build-essential python3-dev \
|
|
&& rm -rf /var/lib/apt/lists/* \
|
|
&& cmake --version | head -1 \
|
|
&& c++ --version | head -1 \
|
|
&& ls /usr/lib/*/libpython3*.so | head -1
|