Generate k8s manifests for recipes by canercidam · Pull Request #404 · flashbots/builder-playground

canercidam · 2026-03-20T03:24:23Z

New command builder-playground dir which can be used like cd $(builder-playground dir)/k8s to navigate to the k8s files of the latest run
New --k8s flag for start. Usage:
- Checkout to this branch, do go install . or do go build . and use local binary
- Install kompose CLI
- To try with L1 recipe, builder-playground start l1 --dry-run --k8s
- cd $(builder-playground dir)/k8s
- In one terminal, do ./minikube-mount.sh
- On the second terminal, do minikube start if you haven't started yet and do kubectl apply -f .
- See from minikube dashboard
- On another terminal, kubectl port-forward service/el 8545:8545
- And builder-playground test to verify that the deployed stack can build a new block with a new tx

I tested this with the opstack recipe. It doesn't work yet but we're close.

The outputted files are useful for kickstarting a k8s setup and iterating from there. Playground doesn't deploy to k8s yet.

claude · 2026-03-20T03:24:45Z

Claude finished @canercidam's task in 1m 49s —— View job

Review of PR #404: Generate k8s manifests for recipes

Read all changed files
Review code quality, bugs, security, and performance
Post inline comments and summary

Summary

This PR adds k8s manifest generation by shelling out to kompose and then patching the output. The approach is reasonable for kickstarting a k8s setup, but there are several issues to address:

Bugs:

Command injection in minikube-mount.sh — host paths are interpolated into the shell script without escaping. Paths with spaces or metacharacters will break or execute arbitrary commands.
:ro/:rw volume suffixes not handled — SplitN(vol, ":", 2) leaves options like :ro attached to the container path, producing incorrect mount paths.
os.Stat for volume classification is host-dependent — whether a volume is treated as a file or directory depends on the filesystem state of the machine running generation, making output non-deterministic across environments (local dev vs CI).

Design issues:

--k8s silently implies --dry-run — the flag description doesn't mention this. Users may expect the Docker stack to start alongside manifest generation.
Compose file parsed 3 times — parseNamedDockerVolumes and parseComposeVolumesPerService each independently read and unmarshal the same file. Parse once and share.
No kompose availability check — a missing kompose binary produces a confusing error. exec.LookPath check with a helpful message would improve UX.

Suggestion:

Use gopkg.in/yaml.v3 instead of v2 — since this is a new package, v3's map[string]interface{} default would eliminate the verbose map[interface{}]interface{} casting throughout.

playground/k8sgen/k8s.go

main.go

claude · 2026-03-20T03:26:29Z

playground/k8sgen/k8s.go

+	cmd := exec.Command("kompose", "convert",
+		"-f", composeFile,
+		"--volumes", "hostPath",
+		"-o", k8sDir,
+	)
+	var outBuf, errBuf bytes.Buffer
+	cmd.Stdout = &outBuf
+	cmd.Stderr = &errBuf
+	if err := cmd.Run(); err != nil {
+		return fmt.Errorf("kompose convert failed: %w\n%s", err, errBuf.String())
+	}


Missing kompose availability check. If kompose isn't installed, the error message from cmd.Run() won't be very helpful (exec: "kompose": executable file not found in $PATH buried in the error chain). Consider checking exec.LookPath("kompose") first and returning a user-friendly message like "kompose is required but not found in PATH; install it from https://kompose.io/".

Good to have, will deal with this before merge.

playground/k8sgen/k8s.go

generate k8s manifests for recipes

3463e19