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

[rmems]

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 #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 + #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).

[rmems]

Sibling issue (Azure Pipelines): #8

Both follow the pattern from corinth-canal #109 (Azure) and its docker-build.yml for org consistency. See plan for details. Cross-platform + containerized verification for this pure-Rust zero-dep crate.

[rmems]

New CI/CD improvement issues created (better GH + security + releases + MSRV + dependabot + layout hygiene, per approved plan). Cross-links:

• ci: harden and enhance GitHub Actions workflow (adopt corinth-canal patterns: pinned SHAs, rust-cache, llvm-cov + Codecov, schedule, concurrency) #11 harden/enhance GH Actions (pinned SHAs, coverage with Codecov, etc.)
• ci: add security scanning workflow (RustSec audit + Snyk SCA/SAST with SARIF, modeled on corinth-canal) #12 security scanning (RustSec + Snyk)
• ci: add GitHub Releases on tags (can use sentry; no automated crates.io release) #13 GH releases on tags (sentry possible; no crates.io auto)
• ci: establish Minimum Supported Rust Version (MSRV) policy and test it in CI #14 MSRV policy + CI test
• repo: add Dependabot for GitHub Actions and future dependencies #15 Dependabot (no auto-merge)
• repo: clean up duplicated source layout and publish artifacts (engram-parser/ nested dir) #16 layout clean (nested dir etc.)

See #8 (Azure) too. All build on the existing CI baseline + corinth/neuromod patterns for Limen-Neural DX (LIM-9). Grok Build assisted drafting. (Separate ymls preferred where it makes sense.)