GGateTest

Quickstart

First result, then the gate.

Scan on your machine, connect the repository, capture a baseline so only new findings count, then open a pull request. Every step works without a model provider key.

  1. Step 1

    Scan on your machine

    From the root of any repository. Node 20 or newer, no account, no install step.

    npx -p @gatetest/cli gatetest --suite quick

    Your code stays on your machine. Anonymous module counts are sent unless GATETEST_NO_TELEMETRY=1. The report ends with what was not checked, so a short run never reads as a clean one.

  2. Step 2

    Connect the repository

    Install the GitHub App to check every push and pull request. It starts in advisory mode: nothing blocks until you set "mode": "strict" in .gatetest.json. The install page lists every permission the App asks for.

    Install the GitHub App

    On another git host, skip this step: the CI line in step 4 runs the gate in your own pipeline.

  3. Step 3

    Capture a baseline

    Records every current finding in .gatetest/baseline.json, so the CLI and the CI line fail only on new ones. It also prints a reportOnlyUntil date 14 days out for .gatetest.json: until then they report and never block.

    npx -p @gatetest/cli gatetest baseline --init

    Paste the printed snippet into .gatetest.json (the wizard writes only the baseline file), then commit both:

    git add .gatetest/baseline.json .gatetest.json git commit -m "chore: GateTest baseline"

    How baseline, report-only and strict fit together

  4. Step 4

    Open your first pull request

    With the App, the pull request gets a check and a comment on the lines it changed. Findings in files it did not touch are labelled pre-existing and never fail its check. The App does not read the baseline file yet; its switch is "mode": "strict".

    In any other CI, add this line to the job:

    npx -p @gatetest/cli gatetest --suite standard --sarif --junit --parallel

    Before the reportOnlyUntil date the line never fails the job. From that date, only findings that are not in the baseline fail it. Baselined findings stay visible in every report.

  5. Optional

    Auto-fix with a model provider key

    The gate above runs without a key. A model provider key adds gatetest fix --apply, which proposes fixes for you to review. Set it as ANTHROPIC_API_KEY in your shell or as a CI secret; usage is billed to your own provider account, and GateTest never stores the key.

Common questions

The first scan blocked on code we did not write.

That is the backlog, not this change. Step 3 grandfathers it: run npx -p @gatetest/cli gatetest baseline --init, commit the file, and from then on only new findings block.

We use GitLab, CircleCI or Bitbucket, not GitHub.

npx -p @gatetest/cli gatetest --ci-init gitlab writes a complete .gitlab-ci.yml, --ci-init circleci writes .circleci/config.yml and --ci-init bitbucket writes bitbucket-pipelines.yml. It never overwrites a pipeline file you already have. On any other CI, the line in step 4 runs from your pipeline; --suite full runs every module that applies to a repository, out of 122 in the engine.

How do we make the gate block?

Two switches, both in .gatetest.json. For the CLI and the CI line, the reportOnlyUntil date ends report-only on its own. On the GitHub App, "mode": "strict" turns the advisory check into a failing one. Details.

Next