👨🏾‍💼Mr Milchick

A pleasantly unsettling steward for merge requests.

Documentation | Examples | Contributing

Overview

Mr Milchick is a Rust CLI for GitLab merge request pipelines. It runs as a single CI job, reads the merge request context, evaluates review policy, plans reviewer and summary actions, and can sync the result back to GitLab 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 small: GitLab is the only review connector, and Slack app plus Slack workflow are the only 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 and Slack integrations
• apps/mr-milchick/src/app.rs: CLI orchestration and command flow

Quickstart

The example below builds the binary in GitLab CI, 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 and notifications.

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 slack-workflow"
    - 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. For Slack workflow delivery, also provide MR_MILCHICK_SLACK_WEBHOOK_URL and MR_MILCHICK_SLACK_CHANNEL. For Slack app delivery, provide MR_MILCHICK_SLACK_BOT_TOKEN and MR_MILCHICK_SLACK_CHANNEL, and optionally MR_MILCHICK_SLACK_USER_MAP if you want GitLab usernames rewritten to Slack user IDs. 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.