Mr Milchick

A pleasantly unsettling steward for merge requests.

Documentation | Examples | Contributing

Overview

Mr Milchick is a Rust CLI for GitLab merge request pipelines and GitHub pull request workflows. It runs as a single CI job, reads the active review context, evaluates review policy, plans reviewer and summary actions, and can sync the result back to the review platform with optional Slack notifications. It is a binary (that cares), not a bot and not a long-running service.

Purpose

The tool exists to keep review governance where the decision already happens: inside CI. It turns reviewer routing, CODEOWNERS coverage, and blocking policy into deterministic pipeline behavior that stays visible in code review and easy to audit later.

How It Works

observe runs the planning flow without mutating anything. refine executes the same plan for real, including reviewer assignment, summary comment sync, optional Slack delivery, and pipeline failure when blocking policy remains unresolved. explain adds deeper routing and CODEOWNERS detail for debugging, while version prints build metadata and the compiled capabilities in the artifact you are actually running.

Today the implemented surface is intentionally focused: GitLab and GitHub are the supported platform connectors, and Slack app plus Slack workflow are optional notification sinks.

Internally, the repository now ships as a single crate with layered modules:

• apps/mr-milchick/src/core: pure policy, routing, CODEOWNERS, rendering, and tone logic
• apps/mr-milchick/src/runtime: execution traits, capability wiring, and reporting
• apps/mr-milchick/src/connectors: GitLab, GitHub, and optional Slack integrations
• apps/mr-milchick/src/app.rs: CLI orchestration and command flow

Quickstart

The example below builds the binary in GitLab CI with the GitLab platform connector plus Slack app support, prints the compiled capabilities, and runs it for merge request pipelines. Start with observe while rolling out, then switch the review job to refine when you want live reviewer assignment. GitHub release automation now lives in .github/workflows/release.yml, and .github/workflows/review.yml uses mr-milchick.github.toml for GitHub pull request runs.

stages:
  - build
  - review

variables:
  MR_MILCHICK_REVIEWERS: >-
    [{"username":"milchick-duty","fallback":true},
     {"username":"principal-reviewer","mandatory":true},
     {"username":"alice","areas":["frontend","packages"]},
     {"username":"carol","areas":["backend"]}]

build:milchick:
  stage: build
  image: rust:1.87
  before_script:
    - rustup target add x86_64-unknown-linux-musl
    - apt-get update && apt-get install -y musl-tools pkg-config
  script:
    - cargo build --release --target x86_64-unknown-linux-musl --no-default-features --features "gitlab slack-app"
    - mkdir -p dist
    - cp target/x86_64-unknown-linux-musl/release/mr-milchick dist/
  artifacts:
    paths:
      - dist/mr-milchick

milchick:review:
  stage: review
  image: debian:bookworm-slim
  needs: ["build:milchick"]
  script:
    - ./dist/mr-milchick version
    - ./dist/mr-milchick observe
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

To make that pipeline work, store GITLAB_TOKEN as a CI secret. This build shape includes Slack app support, so you can enable it in mr-milchick.toml whenever you are ready and then provide MR_MILCHICK_SLACK_BOT_TOKEN, MR_MILCHICK_SLACK_CHANNEL, and optionally MR_MILCHICK_SLACK_USER_MAP. If you prefer Slack workflow delivery instead, switch the feature set and notification config intentionally. A deeper setup guide, including mr-milchick.toml, rollout steps, and both Slack variants, lives in docs/ci-quickstart.md.

You can always fetch the latest binary, but inside sensitive infrastructures it's much better to build it directly there and use it locally.

Publishing

Mr Milchick now publishes as a single crates.io package. The root of the repository is the publishable crate, so the release flow is just:

cargo publish --dry-run
cargo publish

There is no internal multi-crate publish ordering anymore.

Docs

The main documentation hub is docs/README.md. From there you can jump straight to:

• CI quickstart
• Configuration reference
• Reviewer routing and CODEOWNERS
• Connectors and compiled capabilities
• Architecture
• Tone and messages
• Local testing

Direction

The project is moving toward stronger connector boundaries, clearer capability reporting, and deeper governance behavior without adding service infrastructure. Future connector names may already exist as reserved Cargo features, but the supported runtime surface should always be read from the current docs and the version command output.

Contributing

Contributions should preserve determinism, clear architectural boundaries, and calm operational output. See CONTRIBUTING.md for the workflow and coding expectations.

Security

See SECURITY.md for reporting guidance and operational expectations.

License

Released under the MIT license. See LICENSE.