Connect a repository

Your codebase, drawn from your own pipeline

The scan runs in your CI, on a checkout that is already there. What reaches us is the graph it built — files, symbols, the edges between them, and what the rules found. Never your source, never a diff, never a patch. There is no column in our database that could hold one, and a build gate fails if somebody adds a place for it.

Step 1: A key for this organisation
A scan belongs to an organisation, and the key is how your pipeline says which one it is. Signing up creates the organisation — there is nothing else to fill in.
Make an account
2
Step 2: Install it
One package, one dependency of its own. It reads your repository and writes a report; it never runs your code, never installs anything, and never reaches the network except to send the report here.
in your repository
```
npm i -D mlreps
```
3
Step 3: Publish on every push to main
This is what keeps your dashboard current. It runs on the default branch rather than on pull requests on purpose — a report published from every branch would make this a picture of whichever job finished last, not of your codebase.
.github/workflows/mlreps.yml
```
name: MLReps

on:
  push:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          # Without this the scan reports that every file was never committed.
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm ci
      - run: npx mlreps scan . --publish
        env:
          MLREPS_KEY: ${{ secrets.MLREPS_KEY }}
```
Add the key as a repository secret named MLREPS_KEY. The endpoint is /api/scan/v1/report, and the response to every publish is the diagnostic: what we stored, what we could not read, and what was swept out of it.

Step 4: And on pull requests, if you want it

A second, separate workflow puts what a change reaches onto the pull request as a check run. It carries no credential of ours and sends us nothing — the analysis runs on your machine and the result is posted to your repository by your own CI token. It is the stronger arrangement of the two and it costs you the dashboard, which is why both are offered rather than one.

.github/workflows/codebase.yml

name: Codebase intelligence

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: 22
      - run: npm ci
      - 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 }}

Step 5: Then look at it
Every screen leads with how much of your codebase we could read — because a region we could not parse must never be drawn as a region with nothing wrong in it.
Open the dashboard Your repositories

Outside GitHub Actions

Nothing above is specific to Actions beyond the check run. On GitLab, Bitbucket, Jenkins or a laptop, set these two and run npx mlreps scan . --publish.

environment

MLREPS_KEY=<your project key>
MLREPS_ENDPOINT=https://dev.mlreps.com

Add --dry-run to see exactly what would be sent without sending it. A checkout with no remote is refused rather than guessed at — a scan has to be filed under a repository name, and a folder name is not one.

Publish on every push to main

This is what keeps your dashboard current. It runs on the default branch rather than on pull requests on purpose — a report published from every branch would make this a picture of whichever job finished last, not of your codebase.

.github/workflows/mlreps.yml

name: MLReps

on:
  push:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          # Without this the scan reports that every file was never committed.
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm ci
      - run: npx mlreps scan . --publish
        env:
          MLREPS_KEY: ${{ secrets.MLREPS_KEY }}

Add the key as a repository secret named MLREPS_KEY. The endpoint is /api/scan/v1/report, and the response to every publish is the diagnostic: what we stored, what we could not read, and what was swept out of it.

And on pull requests, if you want it

.github/workflows/codebase.yml

name: Codebase intelligence

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: 22
      - run: npm ci
      - 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 }}

Outside GitHub Actions

Nothing above is specific to Actions beyond the check run. On GitLab, Bitbucket, Jenkins or a laptop, set these two and run npx mlreps scan . --publish.

environment

MLREPS_KEY=<your project key>
MLREPS_ENDPOINT=https://dev.mlreps.com

Step 1: A key for this organisation

Step 2: Install it

Step 3: Publish on every push to main

Step 4: And on pull requests, if you want it

Step 5: Then look at it

Outside GitHub Actions

Step 1: A key for this organisation

Step 2: Install it

Step 3: Publish on every push to main

Step 4: And on pull requests, if you want it

Step 5: Then look at it

Outside GitHub Actions