Skip to content
MLReps
Sign in
Sign in
Back to the three ways in

Run it locally

Run it on your own machines

The scan runs in your own build pipeline (CI), on code that is already checked out there, using the access your build job already has. Nothing is sent to us — not your source, not the findings, not a list of your files. This way needs no account and no key.

That is because the analysis happens on your runner (the machine your pipeline runs on), not on ours. Analysing code can mean running it, so scanning somebody else’s repository on our side needs a sandbox — a sealed-off space to run it in. This way needs no sandbox at all, because nothing of yours is on our side. It works today, and it sends us nothing.

  1. Try it on the repository you are standing in

    It prints what it found and always finishes with success (exit code zero), so it never breaks a build — including its own.

    in a terminal

    npx mlreps scan .
npx mlreps check . --dry-run

    --dry-run shows the check it would post on a pull request, without posting it, so you can read what your team would see.

  2. Add the workflow

    Put this file in .github/workflows/. It already has the two lines people usually forget: the permissions block, without which the job cannot post its check, and the head commit, without which the check lands on a temporary merge commit and the pull request shows nothing.

    .github/workflows/codebase.yml

    name: MLReps

on:
  pull_request:

# Without this, GITHUB_TOKEN cannot write a check run and every run ends in a 403.
permissions:
  contents: read
  checks: write

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm install
      - run: npx mlreps check .
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # On a pull request, GITHUB_SHA is a merge commit that exists nowhere in
          # the repository — a check run posted against it is invisible.
          PLATFORM_HEAD_SHA: ${{ github.event.pull_request.head.sha }}

Two surfaces, two audiences

What appears, and where

A check run on the pull request

Counts, file paths and modules, with the most serious findings marked on the exact lines where they are. It never fails a pull request. Its result is always neutral — you decide what to do about each finding.

The full picture, on your machine

mlreps scan . writes a report on your machine. It shows how your code is built, what depends on what, and what a change would affect.

Want it on a dashboard your team can open? Publish it instead.

The other two paths

This one trades the dashboard for sending nothing

Setup has the two ways that publish: your pipeline with a key, or the GitHub App, which analyses pull requests in a sandbox on its own machine. Both give you the dashboard — the architecture map, the findings, the trends — because something of yours reaches us. This way gives you checks on pull requests and nothing else. That is the trade. Anybody can install it, and what it reaches is listed here. That way, your commit is copied to our server and only TypeScript and JavaScript are read; this way, your code never leaves your machines and every language is read. Nothing above depends on it.