feat: combine #9 (Docker workflow + GHCR) and #11 (harden GH Actions CI) into one PR

[rmems]

Summary

Fixes all bugs found by Devin Review in the combined Docker (#9) + CI hardening (#11) PR, plus resolves merge conflicts with main.

Docker fixes (Dockerfile, .dockerignore, docker-build.yml):

• Removed invalid inline comment in .dockerignore that broke COPY Cargo.lock
• CMD ["cargo", "--version"] → CMD ["echo", ...] (cargo not available in debian:stable-slim runtime)
• Removed unnecessary pkg-config/libssl-dev (zero-dep crate)
• Removed no-op dummy-main dep caching layer (nothing to cache with empty [dependencies])
• COPY --from=builder /app/target/release → copy only libengram_parser.rlib
• RUST_VERSION 1.85 → 1.87 to match Cargo.toml rust-version
• Added docker/setup-buildx-action (required for cache-from/to: type=gha)
• Lowercased github.repository in tag script (Docker rejects uppercase)

CI fixes (.github/workflows/ci.yml):

• Consolidated redundant rustup component add rustfmt clippy into dtolnay/rust-toolchain components: field (now clippy, rustfmt, llvm-tools-preview)

Checkout SHA fix (docker-build.yml):

• actions/checkout@93cb6efe... (invalid "v5") → @11bd71901bbe... (v4.2.2, matches ci.yml)

Merge with main:

• Resolved conflicts in cursor.rs, layout.rs, tensor.rs, extract.rs, ci.yml, README.md
• Adopts main's safe chunks_exact approach over unsafe from_raw_parts in tensor readers
• Adopts main's slice_stacked_expert(layout, block, tensor, expert) signature, fixing the hardcoded block: 0 in ExpertOutOfRange error
• Merges main's refactored helper functions (read_tensor_entry, validate_stacked_expert_count, etc.)

Link to Devin session: https://app.devin.ai/sessions/4f1d3f109f70401285b8f5fbd9dd7ed1
Requested by: @rmems

Summary by CodeRabbit

• New Features
  • Added a GitHub Actions workflow to build a CPU-only Docker image and publish it on main branch pushes.
  • Added a .dockerignore to reduce Docker build context.
• Documentation
  • Expanded README with ecosystem/sibling parser notes, full development command set, and clearer Docker/CI guidance.
• Chores
  • Updated CI scheduling/concurrency, caching, and added dedicated coverage generation/upload behavior (including non-blocking upload errors).

Greptile Summary

This PR adds Docker publishing and hardens the Rust CI setup. The main changes are:

• New Docker image build path for the library crate.
• New GHCR workflow for PR builds and main-branch publishing.
• Updated CI caching, coverage generation, and Codecov upload.
• Added Docker and local development guidance in the README.
• Tightened MoE stacked tensor range arithmetic.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
Dockerfile	Adds a Rust 1.87 image that builds and tests the crate.
.github/workflows/docker-build.yml	Adds Docker Buildx builds and gated GHCR publishing.
.github/workflows/ci.yml	Updates Rust components, caching, clean-tree checks, and coverage upload.
.github/codecov.yml	Adds Codecov settings for lcov coverage reports.
src/moe/extract.rs	Uses checked arithmetic for the stacked slice end offset.
.dockerignore	Adds Docker build context exclusions.

_{Reviews (5): Last reviewed commit: "fix: merge publish job back into single ..." | Re-trigger Greptile}

[codeant-ai]

CodeAnt AI is reviewing your PR.

[codeant-ai]

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_2995be4e-fe63-403d-8b73-d45deaa983ee)

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds Docker build inputs, CI coverage and caching updates, a Docker image build workflow with GHCR publishing, and README sections describing the new workflows and related project context.

Changes

CI/CD and Docker setup

Layer / File(s)	Summary
Docker build inputs Dockerfile, .dockerignore	Adds a BuildKit-based Dockerfile that builds and tests the crate during image creation, plus ignore rules for build and git artifacts.
CI workflow and Codecov .github/workflows/ci.yml, .github/codecov.yml	Adds cron scheduling, concurrency cancellation, toolchain and cache updates, coverage generation/upload steps, and a Codecov configuration for Rust reporting.
Docker build workflow .github/workflows/docker-build.yml	Adds a GitHub Actions workflow that computes image tags, authenticates to GHCR on main pushes, and builds or pushes the image with GitHub Actions cache.
README updates README.md	Adds ecosystem, development, Docker, and CI documentation sections that reference the new workflows and related projects.

Estimated code review effort: 2 (Simple) | ~15 minutes

Possibly related issues

• Add Docker workflow for reproducible / containerized builds (publish to GHCR on main) #9: The Docker workflow, Dockerfile, and README updates align with the issue’s Docker-related changes.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: merging the Docker workflow/GHCR and CI hardening work into one PR.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/harden-ci-gh-actions

---

_{Comment @coderabbitai help to get the list of available commands.}

[gemini-code-assist]

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.

[qodo-code-review]

PR Summary by Qodo

Harden GitHub Actions CI with Codecov and add GHCR Docker build workflow

✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 20-40 Minutes

AI Description

• Add hardened GitHub Actions CI with caching, concurrency, scheduled runs, and Codecov coverage
 upload.
• Introduce multi-stage Dockerfile and workflow to build and publish CPU-only images to GHCR.
• Document local development/CI commands and apply rustfmt-driven formatting cleanup.

Diagram

graph TD
  R["GitHub Repo"] --> CI["CI (ci.yml)"] --> BT["Build/Lint/Test"] --> Cov["Generate lcov"] --> Codecov["Codecov"]
  R --> DW["Docker (docker-build.yml)"] --> DB["Build image"] -->|"push main"| GHCR["GHCR"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use docker/metadata-action for tagging

• ➕ Standardized tag/label generation (semver, branch, SHA, PR) with less shell scripting
• ➕ Easier to extend with OCI labels and additional tagging strategies
• ➖ Adds another action dependency to pin and maintain
• ➖ Less explicit than an inline script for reviewers unfamiliar with the action

2. Use cargo-chef for Docker layer caching

• ➕ More reliable dependency-layer caching for Rust builds than a dummy src/main.rs trick
• ➕ Often faster rebuilds on source-only changes
• ➖ Introduces a new tool into the Docker build (extra moving parts)
• ➖ Slightly more complex Dockerfile and debugging experience

3. Publish coverage to GitHub-only (no Codecov)

• ➕ Avoids external service dependency and token management
• ➕ Keeps coverage artifacts within GitHub Actions/Pages ecosystem
• ➖ Less feature-rich reporting/comparisons than Codecov for many teams
• ➖ Requires additional setup to get PR annotations and historical tracking

Recommendation: Current approach is solid for a lightweight Rust crate: pinned actions, minimal permissions, rust-cache, and token-gated Codecov upload reduce CI risk while improving signal. Consider switching Docker tag generation to docker/metadata-action if tagging requirements grow, and revisit cargo-chef only if Docker builds become a bottleneck.

Files changed (11) +300 / -30

Refactor (5) +31 / -29

cursor.rsRustfmt cleanup for numeric type error formatting +3/-3

Rustfmt cleanup for numeric type error formatting

• Reformats the numeric type coercion match arm to satisfy rustfmt without changing behavior. Keeps the same unsupported-type error semantics.

src/gguf/cursor.rs

layout.rsRustfmt cleanup in tensor lookup and layout parsing helpers +16/-8

Rustfmt cleanup in tensor lookup and layout parsing helpers

• Reflows tensor lookup error construction, function signature formatting, and an overflow check chain to match rustfmt output. No logic changes to layout parsing are introduced.

src/gguf/layout.rs

tensor.rsRustfmt cleanup for unsafe slice creation blocks +4/-6

Rustfmt cleanup for unsafe slice creation blocks

• Reformats unsafe slice construction into single-line expressions while preserving existing safety checks. No behavioral changes to tensor reinterpretation APIs.

src/gguf/tensor.rs

lib.rsRustfmt cleanup for public re-export list formatting +1/-3

Rustfmt cleanup for public re-export list formatting

• Collapses the gguf re-export list into a single rustfmt-formatted line. Public API surface is unchanged.

src/lib.rs

extract.rsRustfmt cleanup for stacked expert slicing helpers +7/-9

Rustfmt cleanup for stacked expert slicing helpers

• Reformats helper function signature and checked arithmetic chain for readability/rustfmt compliance. Behavior and error conditions remain the same.

src/moe/extract.rs

Documentation (1) +44 / -1

README.mdDocument ecosystem context plus Development/CI commands and workflows +44/-1

Document ecosystem context plus Development/CI commands and workflows

• Adds ecosystem/sibling parser context and clarifies the no-dependency relationship with external inspiration repos. Documents local dev commands (fmt/clippy/test/coverage) and points to the new CI and Docker workflows.

README.md

Other (5) +225 / -0

.dockerignoreAdd Docker build exclusions for targets and nested workspace dirs +6/-0

Add Docker build exclusions for targets and nested workspace dirs

• Introduces a .dockerignore to keep Docker contexts small and avoid copying build artifacts or nested directories into image builds. Excludes target/, nested engram-parser/, git metadata, and editor backup files.

.dockerignore

codecov.ymlConfigure Codecov status checks and GCOV parsing defaults +24/-0

Configure Codecov status checks and GCOV parsing defaults

• Adds a minimal Codecov configuration enabling CI gating, project/patch statuses, and GCOV branch detection settings. Disables PR comments from Codecov.

.github/codecov.yml

ci.ymlAdd hardened Rust CI with caching, concurrency, schedule, and Codecov upload +75/-0

Add hardened Rust CI with caching, concurrency, schedule, and Codecov upload

• Creates a GitHub Actions CI workflow for main/PR/scheduled runs with concurrency control and pinned actions. Runs fmt, clippy, build, and tests with --all-features, then generates and uploads LCOV coverage via cargo-llvm-cov to Codecov when a token is present.

.github/workflows/ci.yml

docker-build.ymlAdd Docker build workflow with conditional GHCR publish on main +61/-0

Add Docker build workflow with conditional GHCR publish on main

• Adds a GitHub Actions workflow that builds a CPU-only Docker image on PRs and main pushes, using GHA cache for buildx layers. Publishes to GHCR only for pushes to main, and generates tags for SHA, PR number, and main.

.github/workflows/docker-build.yml

DockerfileAdd multi-stage CPU-only Dockerfile for reproducible Rust builds +59/-0

Add multi-stage CPU-only Dockerfile for reproducible Rust builds

• Introduces a multi-stage Dockerfile using a Rust slim builder and a minimal Debian runtime stage. Optimizes caching by copying manifests first and building dependencies before copying full source, and builds with --all-features.

Dockerfile

[codeant-ai]

CodeAnt AI finished reviewing your PR.

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 📜 Skill insights (0)

Context used

✅ Tickets: 🎫 repo: clean up duplicated source layout and publish artifacts (engram-parser/ nested dir) 🎫 Add Docker workflow for reproducible / containerized builds (publish to GHCR on main)

1. packages: write on PRs ✓ Resolved 📎 Requirement gap ⛨ Security

Description

The Docker workflow grants packages: write permission even for PR verification runs. This violates
the minimal-permissions requirement and increases blast radius if the workflow is ever extended to
use the token during PR jobs.

Code

.github/workflows/docker-build.yml[R19-24]

+  build:
+    name: Build Docker Image (CPU-only)
+    permissions:
+      contents: read
+      packages: write
+    # Standard GitHub runners (no self-hosted GPU for this CPU-only crate)

Evidence

PR Compliance ID 7 requires minimal permissions and packages: write only where needed for GHCR
publishing on main. The workflow’s only job unconditionally sets packages: write, so PR builds
receive broader permissions than required.

Create a GitHub Actions Docker workflow that builds on PRs and pushes, and publishes to GHCR only on main
.github/workflows/docker-build.yml[19-24]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Docker workflow requests `packages: write` at the job level for all events, including `pull_request`. Compliance requires minimal permissions and `packages: write` only where needed (publishing on `main`).

## Issue Context
Publishing is already gated to `push` on `main`, so the permission can also be scoped to only the publish job/path by splitting jobs or adjusting workflow structure.

## Fix Focus Areas
- .github/workflows/docker-build.yml[15-24]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. README lacks layout hygiene ✓ Resolved 📎 Requirement gap ⚙ Maintainability

Description

The README updates do not document the repository layout hygiene expectation (clean
single-root/workspace layout and CI expecting a clean tree). Without this guidance, contributors may
reintroduce duplicated directories or generated junk.

Code

README.md[R66-96]

+## Development
+
+This is a pure-Rust, zero-dependency crate. All commands use `--all-features`.
+
+```bash
+# Format
+cargo fmt --check
+
+# Lint (fail on warnings)
+cargo clippy --all-targets --all-features -- -D warnings
+
+# Build
+cargo build --all-features
+
+# Test
+cargo test --all-features
+
+# Coverage (local; uses cargo-llvm-cov)
+cargo llvm-cov --lib --all-features --locked --lcov --output-path lcov.info
+```
+
+## CI
+
+- GitHub Actions: `.github/workflows/ci.yml` (harden in progress via #11; uses Codecov per https://about.codecov.io/language/rust/ )
+- Azure Pipelines: `azure-pipelines.yml` (tracked in #8 for cross-platform ubuntu/mac/windows)
+- Docker: `Dockerfile` + `.github/workflows/docker-build.yml` (tracked in #9 for GHCR reproducible builds; use user's Docker CLI for local verification)
+- Other CI/DX issues: #12 (security), #13 (releases on tags w/ sentry option), #14 (MSRV), #15 (Dependabot no auto-merge), #16 (layout clean)
+
+See the issue bodies for full ACs and corinth-canal inspiration patterns (one-way copy only; no dep on corinth-canal).
+
+Cross-reference: #11, #8, #9, #7, #5, LIM-9.

Evidence

PR Compliance ID 5 requires documenting repository layout hygiene expectations in
README/CONTRIBUTING. The newly added Development/CI sections list commands and workflow references
but do not describe clean-tree/layout hygiene expectations or CI cleanliness enforcement.

Document repository layout hygiene expectation in README or CONTRIBUTING
README.md[66-96]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Contributors need explicit guidance that the repo should remain layout-clean (no duplicated crate roots/directories), that generated junk should be ignored, and that CI expects a clean working tree.

## Issue Context
The PR adds Development/CI sections but does not state the layout hygiene expectations or the clean-tree requirement.

## Fix Focus Areas
- README.md[66-96]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. README lacks Docker instructions ✓ Resolved 📎 Requirement gap ⚙ Maintainability

Description

README.md references the Docker workflow/Dockerfile but does not provide Docker build/run/pull
instructions or the GHCR image name/tags. This fails the documentation requirement for Docker usage
and CI workflow reference.

Code

README.md[R87-92]

+## CI
+
+- GitHub Actions: `.github/workflows/ci.yml` (harden in progress via #11; uses Codecov per https://about.codecov.io/language/rust/ )
+- Azure Pipelines: `azure-pipelines.yml` (tracked in #8 for cross-platform ubuntu/mac/windows)
+- Docker: `Dockerfile` + `.github/workflows/docker-build.yml` (tracked in #9 for GHCR reproducible builds; use user's Docker CLI for local verification)
+- Other CI/DX issues: #12 (security), #13 (releases on tags w/ sentry option), #14 (MSRV), #15 (Dependabot no auto-merge), #16 (layout clean)

Evidence

PR Compliance ID 9 requires a Docker section describing local build/usage plus GHCR image details if
publishing exists. The updated README only mentions Dockerfile and the workflow path without
providing build/run/pull instructions or image/tag information.

Document Docker usage and CI workflow in README
README.md[87-92]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Documentation must include clear Docker usage instructions (local build/verification commands) and, since GHCR publishing is implemented, the GHCR image name/tags and how to pull it.

## Issue Context
The README currently only references the Docker-related files/issues, but does not include actionable Docker commands or published image details.

## Fix Focus Areas
- README.md[87-96]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View more (2)

4. Runtime image missing cargo ✓ Resolved 📎 Requirement gap ≡ Correctness

Description

The Dockerfile’s final image stage is based on debian:stable-slim but sets `CMD ["cargo",
"--version"]` even though Cargo is never installed there, causing the container (and any published
artifact) to fail immediately by default. Because the CI workflow builds/pushes the default final
stage to GHCR on main, this broken default command becomes user-facing and violates the
expectation of a usable image for reproducible verification/builds.

Code

Dockerfile[R43-59]

+# Runtime / verification stage (minimal)
+FROM debian:stable-slim AS runtime
+
+RUN useradd -m -u 10001 appuser
+
+WORKDIR /app
+
+# Copy the built artifacts (for if we expose a binary later, e.g. gguf_smoke)
+COPY --from=builder /app/target/release /app/target/release
+
+# For library use, the image mainly serves as a reproducible build env.
+# You can also cargo install or use as base for downstream.
+
+USER appuser
+
+# Default: show help if a binary is present; otherwise this is a build image
+CMD ["cargo", "--version"]

Evidence

PR Compliance ID 6 requires a usable Dockerfile for reproducible builds/tests, yet the Dockerfile’s
final runtime stage switches to debian:stable-slim and does not include any step that installs
Rust/Cargo while still defining a Cargo-based default CMD, which would result in a
command-not-found failure at container start. The workflow further corroborates the impact by using
docker/build-push-action without specifying a target, meaning the final stage is what gets built
and pushed, so the broken CMD affects the published GHCR image as well.

Add a root Dockerfile for reproducible/containerized Rust builds (CPU-only)
Dockerfile[43-59]
Dockerfile[44-59]
Dockerfile[31-34]
.github/workflows/docker-build.yml[53-61]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Dockerfile’s final `runtime` stage is based on `debian:stable-slim` but sets `CMD ["cargo", "--version"]` even though Cargo is not installed in that stage, so running the image fails immediately. Because CI builds and pushes the default (final) stage, the published GHCR artifact is also broken by default.

## Issue Context
- Compliance expects a Dockerfile that is usable for reproducible/containerized Rust builds/tests.
- The Dockerfile is multi-stage, with a Rust `builder` stage and a minimal `runtime` stage.
- The workflow uses `docker/build-push-action` without specifying a `target`, so it builds/pushes the final stage.
- Fix requires choosing a consistent intent for what gets published/run: either ship a runnable runtime image (with a binary) or ship a build/verification image where `cargo` exists, or keep a minimal runtime stage but avoid a failing default `CMD` and/or adjust the workflow to build a specific target.

## Fix Focus Areas
- Dockerfile[31-34]
- Dockerfile[43-59]
- Dockerfile[44-59]
- .github/workflows/docker-build.yml[53-61]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. ci.yml missing clean-tree guard ✓ Resolved 📎 Requirement gap ☼ Reliability

Description

The new CI workflow does not verify that builds/tests leave the working tree clean (no unexpected
untracked/modified files). This can hide reproducibility/layout regressions and violates the
requirement to fail CI on unexpected tree dirtiness.

Code

.github/workflows/ci.yml[R47-57]

+      - name: Check formatting
+        run: cargo fmt --check
+
+      - name: Clippy (lint)
+        run: cargo clippy --all-targets --all-features -- -D warnings
+
+      - name: Build
+        run: cargo build --all-features
+
+      - name: Test
+        run: cargo test --all-features

Evidence

PR Compliance ID 4 requires CI to detect and fail on unexpected untracked/dirty working tree changes
after build/test steps. The added workflow runs cargo build/cargo test and then generates
lcov.info without any step that checks git status --porcelain/git diff and fails if changes
are present.

Add CI guard to fail when unexpected untracked or modified files are produced by builds (excluding intended artifacts)
.github/workflows/ci.yml[47-57]
.github/workflows/ci.yml[65-67]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
CI must fail if build/test steps produce unexpected untracked or modified files (excluding explicitly allowed artifacts). The current workflow runs build/test/coverage without any post-step guard.

## Issue Context
Per compliance, CI should enforce a clean working tree to prevent accidental generation of nested directories or other repo-junk. Note that `cargo llvm-cov ... --output-path lcov.info` creates `lcov.info`, so the guard should either run before coverage generation and/or explicitly remove/allow that file.

## Fix Focus Areas
- .github/workflows/ci.yml[47-75]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

Qodo Fixer

✅ Committed (5) · ☑ Fixed (5)

Commits pushed directly to this PR — no separate fix PR opened.

Process — 5 fixed

• ☑ Fixed: packages: write on PRs
• ☑ Fixed: README lacks layout hygiene
• ☑ Fixed: README lacks Docker instructions
• ☑ Fixed: Runtime image missing cargo
• ☑ Fixed: ci.yml missing clean-tree guard

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (1 file)

• .github/workflows/docker-build.yml - merged publish job back into build job (incremental)

Incremental Review (since e2a9959)

All 1 changed file reviewed. The incremental change consolidates the previously split build + publish Docker jobs back into a single job to avoid "Skipped" status checks cluttering the PR UI:

• Re-added packages: write at job level with proper if: gating on Login and Push steps
• Login step conditionally runs only on main push events
• Build step uses conditional push: parameter instead of hardcoded true
• Restored cache-to: type=gha,mode=max for complete GHA cache support

No new bugs, security issues, or code quality concerns found in the changed code.

Previous Review Summaries (9 snapshots, latest commit e2a9394)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit e2a9394)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (2 files)

• .github/codecov.yml - removed dead gcov parser config (incremental)
• Dockerfile - reverted cargo fetch that fails without src/ (incremental)

Incremental Review (since daa9959)

All 2 changed files reviewed. The incremental changes are cleanup/corrections:

• .github/codecov.yml: Removed dead parsers.gcov.branch_detection section — CI generates lcov format via cargo llvm-cov --lcov, so gcov parser settings were unused configuration
• Dockerfile: Reverted cargo fetch between manifest COPY and source COPY — cargo fetch requires a build target (src/lib.rs) to parse Cargo.toml, and since source is copied after manifests, the step fails. The Docker layer caching pattern is already handled by separate COPY steps.

No new bugs, security issues, or code quality concerns found in the changed code.

Previous review (commit daa9959)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (2 files)

• .github/workflows/docker-build.yml - cancel-in-progress conditional fix + PR head SHA tagging (incremental)
• Dockerfile - added cargo fetch for future dependency layer caching (incremental)

Incremental Review (since 2c1643e)

All 2 changed files reviewed. The incremental changes are improvements that address prior review findings:

• Docker workflow cancel-in-progress is now conditional on pull_request events only, preventing accidental cancellation of main-branch image publications
• Docker image tagging now uses github.event.pull_request.head.sha for PR builds instead of the merge commit SHA, providing better source traceability
• Dockerfile adds cargo fetch between manifest copy and source copy to establish the layer caching pattern for future dependencies

No new bugs, security issues, or code quality concerns found in the changed code.

Previous review (commit 2c1643e)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (4 files)

• .github/workflows/ci.yml - clean-tree guard step (incremental)
• .github/workflows/docker-build.yml - build/publish split with least-privilege (incremental)
• .gitignore - added local tool entries (incremental)
• src/moe/extract.rs - checked_add overflow safety (incremental)

Incremental Review (since fe1bf98)

All 4 changed files reviewed. The incremental changes are improvements that address prior review findings:

• CI clean-tree guard catches unexpected build artifacts
• Docker build/publish split follows least-privilege principle (build: read-only, publish: write-only on main)
• extract.rs uses checked_add to prevent integer overflow from untrusted GGUF metadata
• .gitignore adds local development tool entries

No new bugs, security issues, or code quality concerns found in the changed code.

Previous review (commit fe1bf98)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (1 file)

• .github/workflows/ci.yml - 0 issues (incremental: concurrency group fix)

---

Previous review (commit 4e90722)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (1 file)

• Dockerfile - 0 issues

---

Previous review (commit 6cf0e32)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (1 file)

• Dockerfile - 0 issues

Fix these issues in Kilo Cloud

Previous review (commit fec8432)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (2 files)

• .github/workflows/ci.yml - 0 issues
• README.md - 0 issues

Fix these issues in Kilo Cloud

Previous review (commit 5a382a4)

Status: 2 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	1
SUGGESTION	1

Issue Details (click to expand)

CRITICAL

File	Line	Issue
Dockerfile	36	USER appuser switches to non-root but build artifacts (/app/target/) are root-owned — CMD cargo test will fail with permission denied

SUGGESTION

File	Line	Issue
Dockerfile	38	CMD missing --release flag — triggers debug recompilation instead of reusing release artifacts from build step

Files Reviewed (21 files)

• .codacy.yml - 0 issues
• .dockerignore - 0 issues (Cargo.lock exclusion fixed)
• .github/workflows/ci.yml - 0 issues (redundant install fixed)
• .github/workflows/docker-build.yml - 0 issues (checkout SHA fixed)
• .yamllint - 0 issues
• CHANGELOG.md - 0 issues
• Cargo.toml - 0 issues
• Dockerfile - 2 issues
• LICENSE-APACHE-2.0 - 0 issues
• LICENSE-MIT - 0 issues
• README.md - 0 issues
• src/error.rs - 0 issues (SPDX header only)
• src/gguf/cursor.rs - 0 issues (refactor + SPDX)
• src/gguf/layout.rs - 0 issues (refactor + SPDX)
• src/gguf/mod.rs - 0 issues (SPDX header only)
• src/gguf/tensor.rs - 0 issues (safe rewrite + SPDX)
• src/lib.rs - 0 issues (SPDX header only)
• src/moe/expert.rs - 0 issues (SPDX header only)
• src/moe/extract.rs - 0 issues (refactor + SPDX)
• src/moe/mod.rs - 0 issues (SPDX header only)
• tests/gguf_smoke.rs - 0 issues (SPDX header only)

Fix these issues in Kilo Cloud

Previous review (commit 2d43222)

Status: 5 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	1
WARNING	3
SUGGESTION	1

Issue Details (click to expand)

CRITICAL

File	Line	Issue
.dockerignore	6	Cargo.lock excluded from build context but Dockerfile:29 COPY requires it — Docker build will fail

WARNING

File	Line	Issue
Dockerfile	59	CMD ["cargo", "--version"] will fail in runtime stage (debian:stable-slim has no cargo)
.github/workflows/ci.yml	38	Redundant rustfmt/clippy install (already set by dtolnay/rust-toolchain)
.github/workflows/docker-build.yml	28	Inconsistent checkout SHA vs ci.yml; comment says v5 (no such release)

SUGGESTION

File	Line	Issue
Dockerfile	23	Unnecessary pkg-config/libssl-dev for zero-dep crate

Files Reviewed (11 files)

• .dockerignore - 1 issue
• .github/codecov.yml - 0 issues
• .github/workflows/ci.yml - 1 issue
• .github/workflows/docker-build.yml - 1 issue
• Dockerfile - 2 issues
• README.md - 0 issues
• src/gguf/cursor.rs - 0 issues (fmt-only)
• src/gguf/layout.rs - 0 issues (fmt-only)
• src/gguf/tensor.rs - 0 issues (fmt-only)
• src/lib.rs - 0 issues (fmt-only)
• src/moe/extract.rs - 0 issues (fmt-only)

Fix these issues in Kilo Cloud

---

_{Reviewed by mimo-v2.5 · Input: 100.7K · Output: 6.7K · Cached: 583.3K}

[codeant-ai]

CodeAnt AI is running Incremental review

[codeant-ai]

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

Dockerfile (1)

22-38: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

appuser doesn't own /app, so the default CMD will fail with permission denied.

useradd runs at Line 22, but /app and its contents (including /app/target built at Lines 33-34) are all owned by root, since every COPY/RUN before USER appuser (Line 36) executes as root. When the container runs the default CMD ["cargo", "test", "--all-features"] (Line 38) as appuser, cargo needs write access to /app/target (and potentially the registry cache) to compile the test binaries — but appuser has no write permission there. This directly breaks the documented usage in the README (docker run --rm engram-parser cargo test --all-features).

🐛 Proposed fix

 RUN cargo build --release --all-features && \
     cargo test --release --all-features
 
+RUN chown -R appuser:appuser /app
+
 USER appuser

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@Dockerfile` around lines 22 - 38, The default container user cannot write to
/app or the build artifacts created by the Dockerfile, so the Cargo test command
will fail under appuser. Update the Dockerfile so the /app directory and
relevant contents are owned or writable by appuser before switching users, using
the existing WORKDIR, COPY, cargo build, and USER appuser steps to locate the
change. Ensure the final CMD can run cargo test --all-features without
permission issues by assigning ownership or adjusting permissions for /app and
/app/target after the build.

🧹 Nitpick comments (1)

Dockerfile (1)

33-38: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

CMD test flags diverge from the build-time test invocation.

Line 34 runs cargo test --release --all-features, but the default CMD at Line 38 runs cargo test --all-features without --release. This triggers a separate debug-profile compilation at container start rather than reusing the release artifacts already built and verified in the image, wasting time and (compounding the ownership issue above) requiring extra writable build output.

♻️ Proposed fix

-CMD ["cargo", "test", "--all-features"]
+CMD ["cargo", "test", "--release", "--all-features"]

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@Dockerfile` around lines 33 - 38, The Dockerfile’s default CMD is running
cargo test without the same release profile used during the image build, so it
recompiles in debug mode at startup instead of reusing the verified artifacts.
Update the CMD to match the build-time test invocation by using the same cargo
test flags as the existing release test step, and keep the change consistent
with the RUN cargo build and cargo test sequence already present.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@Dockerfile`:
- Around line 22-38: The default container user cannot write to /app or the
build artifacts created by the Dockerfile, so the Cargo test command will fail
under appuser. Update the Dockerfile so the /app directory and relevant contents
are owned or writable by appuser before switching users, using the existing
WORKDIR, COPY, cargo build, and USER appuser steps to locate the change. Ensure
the final CMD can run cargo test --all-features without permission issues by
assigning ownership or adjusting permissions for /app and /app/target after the
build.

---

Nitpick comments:
In `@Dockerfile`:
- Around line 33-38: The Dockerfile’s default CMD is running cargo test without
the same release profile used during the image build, so it recompiles in debug
mode at startup instead of reusing the verified artifacts. Update the CMD to
match the build-time test invocation by using the same cargo test flags as the
existing release test step, and keep the change consistent with the RUN cargo
build and cargo test sequence already present.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 11c7d360-5659-4f09-ab01-e83831ec283e

📥 Commits

Reviewing files that changed from the base of the PR and between 53e94ad and ce7aeab.

📒 Files selected for processing (2)

• Dockerfile
• README.md

✅ Files skipped from review due to trivial changes (1)

• README.md

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

📝 Info: Dockerfile COPY pattern defeats dependency layer caching

The Dockerfile copies manifests first (COPY Cargo.toml Cargo.lock ./ at line 27), then immediately copies everything (COPY . . at line 30) before any cargo build. The typical Docker caching pattern is: copy manifests → run dependency build → copy source → run full build. Since there's no build step between the two COPYs, the first COPY provides no caching benefit — any source change invalidates the COPY . . layer and triggers a full rebuild anyway. For a zero-dependency crate this is moot today, but the comment "Copy manifests and lock file for reproducibility" is misleading about the actual purpose. If dependencies are ever added, this pattern would need restructuring to actually cache them.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[rmems]

Acknowledged — the separate COPY Cargo.toml/Cargo.lock before COPY . . is kept for organizational clarity and forward compatibility. This crate has zero deps today so there is no caching benefit either way. Adding RUN cargo fetch between the COPYs was attempted but failed because cargo requires a target (src/lib.rs) to parse Cargo.toml. The standard Docker dummy-source pattern was rejected for simplicity in the single-stage design (ce7aeab).

— Cline agent: DeepSeek-v4-pro