Docs · Configuration
Every scanner gets something wrong eventually. The question is whether you can tell it so without turning the gate off. Each control below narrows what blocks — none of them hide a finding from you.
.gatetestignoreA file at your repo root. One rule per line; # comments and blank lines are ignored. Module and rule names are matched case-insensitively.
# One rule from one module
secrets:generic-api-key
# A whole module
deadCode
# A rule everywhere it fires, whichever module raised it
*:trailing-whitespace
# Scope a suppression to a path
secrets:generic-api-key@tests/fixtures/**
# Skip a path entirely
vendor/**| Form | Suppresses |
|---|---|
| module:rule | one rule in one module |
| module:* or module | an entire module |
| *:rule | that rule across all modules |
| module:rule@glob | that rule, only in matching files |
| path/glob/** | any finding whose file matches |
Globs use * (any run within a path segment), ** (any run, crossing /) and ? (one character).
suppressedChecks list. The distinction matters: “we don't block on this” is a decision you can revisit, “we pretend it isn't there” isn't. vendor/** says “this isn't our code,” so it says nothing about whether a module is accurate. Only module-scoped entries feed the auto-softening below — excluding a fixture directory should not teach the engine to distrust a module that was right.gatetest --noiseRanks modules by how often they fire against how often you dismiss them, learned from this repo's own scan history, and prints the exact ignore line to copy.
$ gatetest --noise
GateTest — module noise report
(learned from this repo's scan history: .gatetest/memory.json)
module fires dismissed status
──────────────────────────────────────────────────────
hardcodedUrl 100% (63/63) 38 softened (x0.5)
moneyFloat 84% (53/63) 38 softened (x0.5)
lint 100% (63/63) 0 high-fireA module you keep dismissing stops blocking the gate on its own. It takes repeated dismissals at a high fire-rate — never a single one — so a module that is occasionally wrong keeps its teeth while one that is reliably wrong for your codebase loses them. Softened modules still report; they just stop failing the build. --noise shows which ones are in that state.
Point any scanner at a mature codebase and the first run is a backlog you didn't write. Baseline mode grandfathers everything that exists today, so the gate only ever fails on new findings.
# Snapshot every current finding, then commit the file
gatetest --baseline
git add .gatetest/baseline.json && git commit -m "chore: baseline GateTest"
# From now on the gate blocks only on findings that aren't in it
gatetest --suite fullThe count is tracked per file, so you can't sneak a new problem in behind an old one — add a second empty catch to a file that already had one baselined and the gate blocks again. Refresh with gatetest --baseline after paying down debt, or delete .gatetest/baseline.json to see everything again. More in the quickstart.
The check GateTest posts on a commit is decided by three questions, in this order. A finding has to answer yes to all of them to turn the check red.
{ "mode": "strict" } in .gatetest.json to enforce.A scan that did not complete is reported as an error in every mode — that is a GateTest problem, and it is never shown as a green tick. Findings you dismiss with .gatetestignore are out of the decision entirely, and cross-module duplicates of the same line count once.
.gatetest.jsonProject-wide options: which suite runs, per-module configuration, and severity overrides. Scaffold one with gatetest --init rather than writing it from scratch — the generated file reflects the options your installed version actually supports.
Two flags worth knowing while you triage: --report-only surfaces everything without failing the build, and --strict forces enforcement back on when you're ready. Use --report-only to see the shape of the problem, then baseline it and turn the gate on — leaving a gate permanently in report-only is how teams end up with a scanner nobody reads.
| Situation | Reach for |
|---|---|
| This finding is simply wrong here | .gatetestignore |
| Turning it on over years of existing code | gatetest --baseline |
| A whole module is wrong for our stack | .gatetestignore (module) or a severity override |
| I want to see everything before deciding | --report-only, then --noise |