Does the shared ARC runner now support Docker-in-Docker / image builds? (MendysRobotics CI)

[izzywdev]

@claude — follow-up to the MendysRobotics ARC onboarding (FuzeInfra #225). We want to move our CI off hosted GitHub runners (we keep hitting the minutes cap), including our image builds (build-and-push.yml runs docker buildx to build+push ~5 images to GHCR).

The docs we read (runners/README.md, runners/arc/ONBOARD-REPO.md) say the hardened staging runner pods are non-root with dropped capabilities and can't run docker/kind — that a separate docker-capable kind-host runner is needed for anything requiring Docker. But we were told the self-hosted runner may since have been upgraded to support DinD, and the docs may be stale.

Could you confirm the current reality:

1. Does the shared ARC runner (or the per-repo scale sets like the mendysrobotics one from Onboard izzywdev/MendysRobotics to the shared ARC self-hosted runner (scale set: mendysrobotics) #225) now support Docker-in-Docker / privileged image builds? (e.g. a DinD sidecar, mounted docker socket, or rootless buildkit in the runner image.)
2. If yes — what runs-on: label / scale-set should MendysRobotics target for build-and-push (docker buildx) jobs, and are there any constraints (registry auth, buildkit endpoint, resource limits)?
3. If no — is there a docker-capable runner (the kind-host one, or another) we can be allowlisted onto for image builds specifically?

Goal: run build-and-push.yml (and ideally the rest of our gates) on FuzeInfra self-hosted runners so our releases don't stall on hosted-Actions minutes. If the docs need updating to reflect a DinD upgrade, a pointer to the current runner image / values would let us wire it correctly.

Refs: FuzeInfra #225 (mendysrobotics scale-set onboarding), MendysRobotics #154 (arc-register), #156 (1.2.0 release that stalled on hosted-runner congestion).

[claude]

Answer: yes for image builds, one extra step for compose (tracked in #236).

After #236 merges and scale sets are re-registered, self-hosted runners get containerMode: dind = a real Docker daemon, so docker buildx build --push (your build-and-push.yml) works self-hosted — no separate kind-host runner needed.

docker compose needs the compose-v2 plugin, which the stock runner image lacks (this is the unknown shorthand flag: 'f' in -f error). Publish runners/arc/Dockerfile and set RUNNER_IMAGE to it to enable compose.

DONE: answered — see #236 for the rollout.

[izzywdev]

@claude the kind-host runner is to support a locally runner on my machine in case I shut down the hosted on contabo. so I would like to keep both options

[claude]

Claude finished @izzywdev's task in 56s —— View job

---

Re: keeping the kind-host runner as a local fallback

Confirmed — both options stay, and nothing in #236 removes kind-host. They're independent by design and can't collide, because they're selected by different runs-on: labels and live on different infrastructure:

	kind-host runner	Contabo ARC scale sets (staging, mendysrobotics, …)
What it is	A classic Actions runner process on your machine (config.sh --labels self-hosted,kind-host)	Ephemeral ARC pods on the Contabo k3s CI node
Docker	Uses your host's Docker + kind directly	containerMode: dind → real Docker daemon per pod
runs-on:	[self-hosted, kind-host]	the scale-set name (e.g. staging, mendysrobotics)
Purpose	Local fallback when you shut Contabo down; the heavy kind-validate full-stack gate	Everyday CI + docker buildx image builds without needing your machine
Lifecycle	You start/stop it (./run.sh or svc.sh)	Argo/ARC scales it 0→N on demand

Because the labels are disjoint, a job only lands on kind-host if it explicitly asks for [self-hosted, kind-host] — the DinD scale-set work in #236 never schedules onto it, and vice-versa. So the two coexist cleanly:

• Contabo up → build-and-push / everyday CI run on the DinD scale sets (no laptop needed).
• Contabo down → jobs pinned to [self-hosted, kind-host] still run on your machine, and you can point others there too as a manual fallback.

The runners/README.md "Host-level kind runner" section (lines 297–345) documenting kind-host stays as-is — the #236 docs refresh only adds the DinD/scale-set reality (which today's runner-scale-set-values.yaml already sets, containerMode: dind at lines 84–91); it doesn't touch the kind-host path.

No code change needed for this — it's already the case. Tracking the DinD rollout + docs refresh in #236 (PR #237).

DONE: confirmed — both runners are kept; kind-host (local fallback) and the DinD Contabo scale sets are orthogonal and selected by distinct runs-on: labels.