Connecting a provider
- Open CI/CD and add a provider. GitHub, GitLab, Jenkins, Azure DevOps and Bitbucket are supported; anything else can use the webhook trigger and a scoped API token.
- Grant the minimum scope the provider needs to read workflow runs and post statuses. Tokens are stored in the credential vault.
- Pick which pipelines report into the platform. Builds, logs and workflow runs become visible in one place alongside test results.
Triggering runs
A pipeline step calls the platform with a scoped CI token, names the project and the suite, and waits for the result or subscribes to a webhook. Tokens are per project and revocable.
curl -X POST "$QAX_URL/api/cicd/runs" \
-H "Authorization: Bearer $QAX_CI_TOKEN" \
-H "Content-Type: application/json" \
-d '{"project":"web-checkout","suite":"regression","ref":"'$GIT_SHA'"}'Quality gates
- Security: fail on any confirmed finding at or above a severity. Unconfirmed observations never fail a gate.
- Regression: fail on any failed step, or on a pass-rate threshold for large suites.
- Accessibility: fail on findings at level A or AA.
- Performance: fail when a percentile regresses beyond a tolerance against the baseline run.
Webhooks and alerting
Run completion, gate results and heal proposals can be delivered to Slack, Microsoft Teams, Opsgenie, PagerDuty or any webhook endpoint. Payloads are signed so the receiver can verify them. DORA metrics (deployment frequency, lead time, change failure rate, time to restore) are computed from the connected providers.
Questions people ask about this
- Is there a CLI or an official GitHub Action?
- Not yet. Triggering is an authenticated HTTP call, which every CI system can make. We will publish an action when it exists rather than list one now.
Source: /documentation/ci-cd-integration, updated 2026-09-18. Answers are checked against the shipped product on that date.
Found something out of date? The people who build the module answer the contact form on the home page, and corrections to this guide are dated above. Tell us.