Notra in GitLab CI.
Same gate, different pipeline: one job after your deploy that starts an audit against the freshly-deployed target and fails the pipeline if a verified critical or high finding shipped. No runner plugin, no special integration — any job that can run curl and bash can gate on Notra. (On GitHub Actions? The GitHub Actions version uses the same script unchanged.)
How the gate works
Start the audit
The job starts a Notra audit against the environment that just deployed — the same scan, with the same verified findings, as the dashboard would run.
Poll, don't block
Audits take minutes, so the script polls a cheap status read rather than holding a single HTTP request open inside the job.
Fail the pipeline
The gate reads the scan's stored severity counts and exits non-zero if anything at or above your threshold shipped — verified findings only, each with its own proof.
What the job looks like
The gate script (notra-gate.sh) handles the start → poll → exit-code sequence. It is a small, readable bash file — vendor it into the repo instead of fetching it at CI time if you want the supply chain pinned.
# Illustrative shape, not a copy-paste contract — the endpoints, auth, and the
# gate script's env contract are documented at /docs/ci-cd and /docs/api.
notra_gate:
stage: deploy-test # run after the target is actually deployed
image: curlimages/curl:latest # anything with curl + a shell works
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
variables:
NOTRA_TARGET: staging.example.com
NOTRA_FAIL_ON: high # critical | high | medium | low | info (default high)
script:
- curl -O https://your-notra-domain/notra-gate.sh
- chmod +x notra-gate.sh
- ./notra-gate.sh
# exit 0 = pass · 1 = findings at/above threshold · 2 = could not start / timed out
# Store the dashboard API key as a masked CI/CD variable named NOTRA_API_KEY
# (Settings → CI/CD → Variables) — the gate script reads it from the environment.The key lives in a masked CI/CD variable, not the YAML. The exact endpoints, auth header, and the gate script's env contract are documented in the CI/CD gate docs and the API reference.
Before your first run
A masked variable
Generate an API key in the Notra dashboard and add it as a masked CI/CD variable. It is org-scoped and bearer-authenticated — same handling as any deploy secret.
An authorized domain
The target must already be ownership-verified for your org, the same gate as a dashboard scan. The API refuses to scan a domain you cannot prove you own.
A scan credit
The gate runs a real audit and consumes a credit like one. If the org is out, the API says so and links the checkout instead of failing silently.
Questions before you wire it up
Do I need a special runner, plugin, or integration?
No. The gate is a shell script and a REST call, so it runs in any job whose image has curl and a shell — no GitLab-specific integration exists or is needed. The same script gates the GitHub Actions workflow on the sibling page unchanged.
Where should the job run in the pipeline?
After the environment is actually up — a deploy stage or a post-deploy test stage — so the audit hits the code that shipped, not the build artifact. If you gate merge requests instead, point NOTRA_TARGET at the review environment that stage creates.
What if the audit is still running when the job checks?
The gate script handles the wait: it starts the scan, polls the cheap status read, and only exits once there is a verdict. Exits 0 on pass, 1 if findings at or above your threshold shipped, 2 if the audit could not start or the wait timed out — so a flaky network reads differently from a red gate.
The endpoints, auth, error codes, and the gate script's env contract live in two short docs pages — the snippet above deliberately points at them instead of duplicating the contract.
Related: the CI/CD gate reference, the REST API, the GitHub Actions variant, running Notra from your AI assistant via the MCP server, and a sample verified report.