plugin-build

Repo	box/github.com/opencharly/plugin-build:v2026.296.1104
Plugin	yes — see the plugin reference

The BUILD-DRIVE plugin: it OWNS the build drive — BuildKit is the builder (the build-order loop, the per-image build lock, the push, and the merge gate) for build:box (the charly box build engine) and build:generate (the charly box generate engine), AND the ensure-image ORCHESTRATION for build:ensure (core-min wave 3, build-engine cluster relocation — the former core ensure-image + cross-engine-transfer helpers): pull an image, falling back to a local (or remote-cached) build reached via the SAME in-process build:box drive this candy already owns — no new build seam. The heavy loader/render RESOLVE runs PLUGIN-SIDE ITSELF (resolveBuildEngine, K3 U6 — the former host-side NewGenerator this candy used to call over HostBuild is DELETED, #55 step3 3-II), reaching the host only for what a sdk-only candy structurally cannot do (the bootstrap-delicate local scan, the git fetch, the build-time plugin connect, the host-fs prep) over a small buildengine-* HostBuild leg family; the layer MERGE crosses to verb:oci via InvokeProvider (no HostBuild(“merge”) seam). Each image is built with BuildKit, its export NAMED with io.containerd.image.name=<FullTag>, written to the engine-neutral CHARLY IMAGE STORE (one OCI layout at $XDG_DATA_HOME/charly/images, see imagestore.go), and materialised into the configured container backend with NO tag step — the annotation names the image on load. A parent box present in the store is supplied to the solve as an --oci-layout named context (buildkitdrive.Build.OCILayouts), so a box-on-box build does not reach the registry for it; each image is ALSO pushed to the LOCAL CHARLY OCI REGISTRY under the same FullTag, which the daemon mirrors ghcr.io/opencharly to, so any base the store does not hold resolves internally rather than against the upstream registry. build:generate renders the .build/ Containerfile tree in its own code (via sdk/deploykit, #67) and returns the written paths (no podman, no merge); build:ensure resolves a project-authored image identifier against charly.yml PLUGIN-SIDE (loaderkit.LoadUnified via the K1 loader reverse legs — no “box-ref-resolve” HostBuild seam, shed #55 coneK1 #8) and a remote @github.com/… identifier via HostBuild(“remote-image-resolve”, …) (git clone/cache ONLY, then plugin-side resolve), then pulls/tags through the resolved run engine’s binary from the engine capability table (no engine word literal, no seam needed — same host, same privilege as the build drive). Only the wire envelopes cross the seam; the engine exec happens IN the candy. COMPILED-IN (in the embedded compiled_plugins:) — charly box build / charly box generate / every dispatchBuildEnsure caller dispatch it IN-PROCESS, the host threading the reverse channel onto the Invoke context so HostBuild is reachable without a go-plugin broker. Also serves out-of-process via cmd/serve for module-shape parity (one provider, two placements).

Acceptance plan

This candy’s plan: — the runnable spec charly check executes against a live deployment. check: steps are idempotent probes; run: steps change state.

Intent

Step

check

the build-drive plugin ships a buildable Go module the host compiles in (default) or serves out-of-process; its build:box / build:generate / build:ensure words own the build drive (BuildKit via the buildkitdrive kit, bridged into the run engine’s store) + the ensure-image orchestration and resolve/merge over the F10 HostBuild seam, exercised by EVERY box build and every image-ensure fallback across the whole ecosystem (every charly box build / charly box generate / charly box pull / deploy image-preflight invocation)