Thales Maciel
942d242c03
Reduce the control plane's dependency on helper scripts while keeping the hard Linux integration points in the approved shell-out layer. Replace the bash-driven image build path with a native Go builder that clones and optionally resizes the rootfs, boots a temporary Firecracker VM, provisions the guest over SSH, installs packages and modules, and preserves the package-manifest sidecar. Also replace a few small convenience shell-outs with Go helpers: read process stats from /proc, use os.Truncate for ext4 image growth, add file-clone and normalized-line helpers, drop the sh -c work-disk flattening path, and launch Firecracker via a direct sudo command. Add tests for the new SSH/archive and system helpers, plus a policy test that keeps os/exec imports confined to cli/firecracker/system. Update the docs to describe customize.sh as a manual helper rather than the daemon's image-build backend. Validated with go mod tidy, go test ./..., and make build.
40 lines
2.7 KiB
Markdown
40 lines
2.7 KiB
Markdown
# Repository Guidelines
|
|
|
|
## Project Structure & Module Organization
|
|
- `cmd/banger` and `cmd/bangerd` are the primary user-facing entrypoints.
|
|
- `internal/` contains the daemon, CLI, RPC, storage, Firecracker, and system integration code.
|
|
- `customize.sh`, `make-rootfs.sh`, and `interactive.sh` remain as manual rootfs/customization helpers; normal VM lifecycle, NAT, `.vm` DNS, and daemon-driven image builds are handled by the Go control plane.
|
|
- Source checkouts use a generated `./runtime/` bundle for Firecracker, kernels, modules, rootfs images, and helper copies. Bundle defaults come from `./runtime/bundle.json` when present. Those runtime artifacts are not meant to be tracked directly in Git.
|
|
- The daemon keeps state under XDG directories rather than the old repo-local `state/` layout.
|
|
|
|
## Build, Test, and Development Commands
|
|
- `make build` builds `./banger` and `./bangerd`.
|
|
- `make runtime-bundle` bootstraps `./runtime/` from the archive referenced by `RUNTIME_MANIFEST`; the checked-in `runtime-bundle.toml` is only a template.
|
|
- `banger` validates required host tools per command and reports actionable missing-tool errors; do not assume one workstation's package set.
|
|
- `./banger vm create --name testbox` creates and starts a VM.
|
|
- `./banger vm ssh testbox` connects to a running guest.
|
|
- `./banger vm stop testbox` stops a VM while preserving its disks.
|
|
- `./banger tui` launches the terminal UI.
|
|
- `make test` runs `go test ./...`.
|
|
- `./verify.sh` runs the smoke test for the Go VM workflow.
|
|
|
|
## Coding Style & Naming Conventions
|
|
- Go code should stay small, direct, and standard-library-first unless there is a clear reason otherwise.
|
|
- Shell helpers use Bash with `set -euo pipefail`; keep remaining shell scripts strict and explicit.
|
|
- Prefer lowercase filenames with short descriptive names.
|
|
- Use `gofmt` for Go formatting; no extra formatter is configured for shell files.
|
|
|
|
## Testing Guidelines
|
|
- Primary automated coverage is `go test ./...`.
|
|
- Manual verification for VM lifecycle changes: `./banger vm create`, confirm SSH access, then stop/delete the VM.
|
|
- If you add a new operational workflow, document how to exercise it in `README.md`.
|
|
- For NAT changes, verify both guest outbound access and host rule cleanup, for example with `./verify.sh --nat`.
|
|
|
|
## Commit & Pull Request Guidelines
|
|
- Git history uses short, imperative subjects.
|
|
- Prefer a real commit body when the change affects lifecycle behavior, storage semantics, or host integration.
|
|
- PRs should call out runtime requirements, migration impact, and any host-side verification performed.
|
|
|
|
## Security & Configuration Tips
|
|
- The VM workflow requires `sudo` and `/dev/kvm` access; do not commit secrets.
|
|
- `id_ed25519` lives inside the runtime bundle; rotate or replace it before publishing a shared bundle.
|