fingerprint-ci-gate

Fail the build, not the ban rate

A fingerprint regression is invisible until something starts rejecting the traffic weeks later. liarjs turns it into a diff in a pull request: scan, save the JSON, compare the next run against the saved baseline.

Node 22 or newer, a Chromium in the image, zero runtime dependencies.

Runner note: give the container enough shared memory (--shm-size=1g on Docker, or a /dev/shm mount) and the capabilities Chrome's own sandbox needs. Leave the browser sandbox enabled; a scan that will not start is an image problem to fix in the image.

The two mechanisms

Absolute floor. Exits 1 when the score is below the number given, so the job fails:

npx [email protected] --headless --min-score 60

Baseline diff. Prints only the checks whose status moved between two saved scans:

npx [email protected] --json scan.json                # write the current result
npx [email protected] diff baseline.json scan.json    # what changed since the known-good run

Prefer the diff in any environment where some checks can never pass. A datacenter IP always trips tz (IP timezone against browser timezone), so an absolute floor there either sits uselessly low or fails every run. The diff only speaks up when something actually moved.

Exit codes: 0 clean, 1 below --min-score, 2 an error such as no browser found.

GitHub Actions

- uses: actions/setup-node@v4
  with:
    node-version: 22

- name: Fingerprint scan
  run: npx [email protected] --headless --json scan.json --min-score 60

- name: Compare against the baseline
  run: npx [email protected] diff baseline.json scan.json

- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: fingerprint-scan
    path: scan.json

references/ci-recipes.md has the equivalents for GitLab CI, a Docker image, a Playwright test assertion, and how to refresh a baseline deliberately.

Choosing the gate

• Pin the version ([email protected] or a dev dependency in the lockfile). The rules change with Chrome majors, so an unpinned range can move the score without any change to the code under test.
• A headless job scores lower than a headed one by design. Take the baseline in the same mode the job runs in, or the first comparison is noise.
• Commit baseline.json and refresh it in its own commit, with the diff output in the message. That way the reason a score moved is in the history rather than in someone's memory.
• Store scan.json as a build artifact. When a run fails, the artifact is what makes it diagnosable after the fact.