Running Compliance Checks in Your CI Pipeline — A 15-Minute Setup

If "are we compliant?" only gets answered when someone manually clicks through a cookie banner before a release, it will eventually get skipped — usually right before the release that needed it most. The fix is the same one you already use for linting and tests: make the machine check it on every push.

This is a 15-minute setup. By the end you will have GDPR consent, WCAG 2.2 accessibility, and security-header checks running in CI, blocking merges when something critical breaks, and a report you can open in GitHub Code Scanning. No account, no API key.

Step 1 — Run it locally first (2 minutes)

Before touching CI, prove it works on your machine. ComplyTest needs no install — npx fetches it and a Chromium binary on first run:

npx complytest scan https://your-site.com

You will get a per-category score across consent, accessibility, security, privacy, and transparency. Read the failing rules. These are the same checks you are about to enforce automatically.

Step 2 — Decide what should block a merge (3 minutes)

You do not want every minor warning to fail the build — you want the critical ones to. ComplyTest exits non-zero when you tell it to with --fail-on:

complytest scan https://your-site.com --fail-on critical

--fail-on accepts more than critical — you can also fail on a score threshold (score<80), a jurisdiction (eaa), or a rule pattern. Start with critical and tighten later. A WCAG CI check is just a build step that fails when accessibility rules in the critical tier break.

Step 3 — Add it to GitHub Actions (5 minutes)

Drop this into .github/workflows/compliance.yml:

name: Compliance
on: [push, pull_request]
jobs:
  complytest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npx complytest scan https://your-site.com --fail-on critical --format sarif
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: reports/complytest.sarif

--format sarif writes a Static Analysis Results Interchange Format report; the upload-sarif step sends it to GitHub Code Scanning so each finding shows up inline on the PR, next to your other code-scanning alerts. The if: always() means you still get the report even when --fail-on critical fails the job.

Step 4 — Cover mobile (2 minutes)

A lot of consent and layout failures only show up on small viewports. Add a second run:

complytest scan https://your-site.com --viewport mobile --fail-on critical

Now your pipeline checks both the desktop (1366×900) and mobile (375×812) renderings of your consent banner and page.

Step 5 — Read the first failing build (3 minutes)

The first run will almost certainly fail something — that is the point. Open the SARIF results in the PR's Code Scanning tab, find the critical rules, and fix them the same way you fix a failing test. Re-push; the job goes green when the critical tier passes.

Where the CLI stops and the audit begins

The CLI gives deterministic pass/fail on 69 rules — perfect for a merge gate. What it does not do is the deep consent-effectiveness audit: driving Reject and Accept separately and verifying the banner actually changed state. If a scanner-clean site can still fail a real audit (and it can — we showed exactly that on Le Monde, Spiegel, and Süddeutsche), CI is your first line of defence and the full audit is your second. Start with CI; it is free and it runs on every push.

The takeaway

Compliance does not have to be a pre-release ritual someone forgets. Fifteen minutes gets you consent, accessibility, and security checks running on every push, blocking merges on critical failures, with results inline on the PR. The command that starts it is one line:

npx complytest scan https://your-site.com --fail-on critical