Skip to content

Features · CI/CD

Fail the build on a bad release

Issue a per-site client secret, run one CLI command from CI, and read an exit code. The branch decides which URL is scanned, through an environment map you keep in settings rather than a config file in the repo.

The parts

What this is made of

Each of these corresponds to a screen or an endpoint you can open today.

  • The secret is per site, issued and revoked from that site's settings.
  • The threshold is the site's own score threshold, so the gate and the alert agree.
  • Available from the Basic plan up.
  • 01

    One command

    npx @pixyscan/scan-sdk run — no config file to commit, no login step, no checkout of a second repository.

  • 02

    Exit codes that mean something

    0 passed, 1 below threshold, and distinct codes for a failed scan and a configuration error, so your pipeline can treat “the site regressed” differently from “the token is wrong”.

  • 03

    Branch to environment

    Map a branch pattern to a URL. A preview deploy is scanned at its own host and filed as preview rather than becoming production's baseline.

  • 04

    Also a library

    The same thing is usable programmatically, with a typed error for the below-threshold case.

In the product

Where you meet it

Captured from the running app, against a real crawl.

app.pixyscan.com/w/…/s/…/settings
Site settings with the SDK and CI/CD tab, where a client secret is issued.
The screens involved:ChangesSettings

Where the line is

What this does not do

You would find out on the trial either way. This is cheaper for both of us.

  • There is no GitHub app. Nothing comments on your pull request or holds a merge — your pipeline decides what a failing scan means.

One of these a blocker for you? Tell us — it is the most useful thing we can hear.

Run it against your own site

One site free, 500 URLs a month, no card. The second scan is where this starts being useful.

Free plan · 1 site · 500 URLs a month · all 100+ checks · no card