fix(eval): use named contexts in bake file so eval→bench/agent dependency is explicit in the build graph

[elronbandel]

Problem

combination.Dockerfile uses ARG-based FROM instructions:

FROM ${AGENT_IMAGE} AS agent
FROM ${BENCHMARK_IMAGE} AS bench
FROM ${RUNTIME_BUNDLE_IMAGE} AS runtime-bundle

ARG-based FROMs are opaque to BuildKit — no graph edge is created. Every bake session that builds eval independently will check the remote registry manifest for these images. On arm64, the registry has only linux/amd64 entries, so the check fails.

The workaround in #199 (adding eval.pull=false via --no-pull) patches the symptom by skipping the manifest check, relying on the images being in the BuildKit content store. This is fragile: it breaks on a cold content store and it leaks the temporal ordering requirement to the caller.

Right fix

Express the dependency in the build graph via named contexts in combination.docker-bake.hcl, the same pattern eval-standalone already uses for eval-base:

target "eval" {
  contexts = {
    agent_image = "target:${agent_target}"
    bench_image = "target:${bench_target}"
  }
}

And in combination.Dockerfile:

FROM agent_image AS agent
FROM bench_image AS bench

Then build eval in the CLI becomes a single bake invocation that includes bench and agent targets. BuildKit's graph scheduler handles ordering automatically — no --no-pull, no content-store dependency, works on any machine including cold CI.

A variable in the HCL can switch between "target:..." (build from source) and a registry URL (pull from registry) to preserve the production pull path.

References

• Closed by fix: remove linux/amd64 platform forcing — fleet is multi-arch after #189 #199 (workaround)
• eval-standalone in combination.docker-bake.hcl already demonstrates the named-context pattern