Add Docker workflow for reproducible / containerized builds (publish to GHCR on main) #9

Summary

Add a Docker workflow (.github/workflows/docker-build.yml or equivalent) for building (and optionally publishing) a container image for reproducible builds and verification. Use a simple multi-stage Dockerfile based on official Rust + cargo images (no CUDA needed for this zero-dep pure CPU crate).

Motivation

• Reproducible environment for cargo build/test/clippy independent of host OS (catches subtle env issues early).
• Potential for GHCR images (e.g. ghcr.io/limen-neural/engram-parser:main) that downstream consumers or examples can use easily.
• Consistency with rmems/corinth-canal (which has .github/workflows/docker-build.yml + open Azure docs: standalone public docs pass for v0.3.0 (RM-1952) #109 for the full CI story).
• Follows the pattern of other Limen-Neural Rust libs for DX and onboarding.

The current CI (.github/workflows/ci.yml) is ubuntu-only in GH Actions. Docker gives containerized verification on every PR/push, with publish only on main (mirroring corinth's split build vs. publish jobs).

Scope

• New Dockerfile (multi-stage: builder with rust + cargo, final minimal image or just for CI verification).
• New workflow in .github/workflows/ (e.g. docker-build.yml):
  • Build on PRs and pushes (push: false for verification; use gha cache).
  • On push to main: login to ghcr.io + build + push with tags for sha + "main".
  • Build args for RUST_VERSION=stable (keep simple; no CUDAHOSTCXX etc.).
  • Concurrency group, permissions (read for build, packages:write for publish).
  • Fork guard if needed (standard runners, so lighter than corinth's self-hosted GPU case).
• Use docker/build-push-action with buildx + gha cache (like corinth).
• Tag logic adapted from corinth (sha always; main on push; pr-### on PRs for verification).

Non-CUDA, CPU-only: just cargo check --all-features or full test inside the image for verification step (optional, since GH already does it; the value is the reproducible image itself).

Non-goals

• Complex multi-arch (arm64 etc.) unless easy win; start linux/amd64.
• Using the image for GPU/CUDA (n/a).
• Replacing the existing GH Actions ci.yml (Docker runs alongside for verification/publish).
• Full app runtime image (this is a library; image is for build env or simple tool usage).
• Self-hosted runners (use standard ubuntu-latest or Docker-in-Docker capable runners).

Acceptance Criteria

• Dockerfile exists at root (or in a docker/ dir) with clear comments.
• .github/workflows/docker-build.yml (or similar name) exists.
• Workflow triggers on PRs and pushes to main.
• Verification job builds the image on PRs/pushes (push: false) and succeeds.
• Publish job only on push to main, logs in to ghcr.io using GITHUB_TOKEN, pushes with proper tags.
• Caching via gha is configured (cache-from / cache-to).
• README.md updated with Docker section (build command, example usage of the image if published, link to workflow).
• Cross-link to the sibling Azure Pipelines issue (and existing ci.yml).
• Workflow respects security (minimal permissions, fork guard if applicable).

Open Questions

• Should we publish a "latest" tag or only sha + main?
• Do we want an example or tool in the image (e.g. the gguf_smoke or a simple manifest tool) or keep it build-env only?
• Multi-arch (linux/arm64) via buildx? (increases build time; can be follow-up).
• Should the Docker job also run cargo test --all-features inside the container for extra verification, or just build?

Related

• .github/workflows/ci.yml (existing GH)
• (Sibling) Azure Pipelines issue (to be created in same batch)
• corinth-canal .github/workflows/docker-build.yml + docs: standalone public docs pass for v0.3.0 (RM-1952) #109 (templates we are adapting; note corinth is CUDA/GPU, this is CPU-only)
• Prior engram CI work (Add GitHub Actions CI workflow for code validation #2 for original GH Actions)
• LIM-9 (org boundary matrix for consistent DX)

Adapted from corinth-canal Docker patterns for a simple pure-Rust lib (no CUDA).