Evaluate container-based builds for language compilation

[richardkiene]

Summary

Evaluate using OCI container images as build environments for language compilation, eliminating the need for local toolchain installation.

Motivation

Instead of requiring users to install TinyGo, .NET SDK, or other toolchains locally, we could leverage container images that have these toolchains pre-installed.

Proposed Approach

1. Pull toolchain image - e.g., docker.io/tinygo/tinygo:0.32.0
2. Mount source code - Bind mount project directory into container
3. Execute build - Run build commands inside container
4. Extract artifacts - Copy compiled WASM out of container

Available Toolchain Images

Language	Image	Notes
Go	tinygo/tinygo	Official TinyGo images
C#/.NET	mcr.microsoft.com/dotnet/sdk	Official .NET SDK
Rust	rust:latest + cargo-component	Would need custom image

Implementation Options

1. bollard crate - Rust Docker API client
2. Shell to CLI - Call docker or podman directly
3. containerd integration - Direct containerd API

Trade-offs

Pros

• No local toolchain installation required
• Consistent, reproducible build environments
• Toolchain versioning via image tags
• Works across all platforms with Docker/Podman

Cons

• Requires Docker or Podman installed
• Container startup overhead on each build
• More complex implementation
• Disk space for cached images

Questions to Answer

1. Is Docker/Podman a reasonable dependency for Fabricks users?
2. Should this be opt-in or the default build method?
3. How do we handle offline scenarios?
4. Should we provide our own curated toolchain images?

Related

• Add Go and C# .NET language support #31 - Go and .NET language support
• Auto-install toolchains for language builders #32 - Auto-install toolchains (alternative approach)