CI, Docker & Release

Core Question

How does this code get from a passing commit to a production artifact that users can trust?

Every merge should produce a verified, reproducible artifact. CI proves correctness, Docker packages the artifact, and release automation delivers it. If any stage is manual, it will eventually be skipped.

Error → Design Question

Quick Decisions

The CI Pipeline

Order matters. Each stage gates the next, and fast checks run first to minimize wasted compute:

1. Format (cargo fmt --check) — instant, catches style drift before anything compiles.
2. Lint (cargo clippy -- -D warnings) — catches logic issues and anti-patterns early.
3. Test (cargo test) — proves correctness.
4. Audit (cargo audit, cargo deny) — checks dependencies for vulnerabilities and license issues.
5. Build (cargo build --release) — produces the artifact only after all checks pass.

If format fails, there is no point running tests. If tests fail, there is no point building a release.

Docker Multi-Stage Build

Separate compilation from runtime. The builder stage has the full toolchain; the runtime stage has only the binary:

FROM rust:1-slim AS builder
WORKDIR /app
COPY Cargo.toml Cargo.lock ./
RUN mkdir src && echo "fn main() {}" > src/main.rs
RUN cargo build --release && rm -rf src target/release/.fingerprint
COPY src ./src
RUN cargo build --release

FROM gcr.io/distroless/cc-debian12
COPY --from=builder /app/target/release/myapp /
ENTRYPOINT ["/myapp"]

The dummy-build trick caches dependencies as a separate layer. Source changes only rebuild app code.

See references/docker.md for musl static linking, .dockerignore, and health check patterns.

Caching Strategy

Cache these:

• ~/.cargo/registry/index
• ~/.cargo/registry/cache
• target/

Never cache these:

• ~/.cargo/registry/src (re-extracted from cache)
• target/debug/incremental (not portable across CI)

Cache key: hash of Cargo.lock + Rust toolchain version. A lockfile change means dependency rebuild.

See references/ci.md for full cache configuration.

Usage Scenarios

Scenario 1: "I'm setting up CI for a new Rust project" → Start with fmt + clippy + test in GitHub Actions. Add Swatinem/rust-cache for caching. Add cargo-audit once dependencies stabilize. See references/ci.md for complete workflow YAML.

Scenario 2: "I need to deploy a Rust service in Docker" → Use a multi-stage Dockerfile with rust:slim as builder and distroless as runtime. Copy Cargo.toml first for layer caching. See references/docker.md for production patterns.

Scenario 3: "I want to release CLI binaries for multiple platforms" → Use cargo-dist to generate GitHub Actions workflows that build and upload binaries on tag push. Configure targets in Cargo.toml. See references/release.md for cargo-dist setup.

Scenario 4: "I need to audit dependencies for vulnerabilities" → Add cargo audit and cargo deny to CI. Configure deny.toml for license and advisory policies. See references/ci.md for deny.toml configuration.

Reference Files

Cross-References