Run tests in CI
CI runs let Qodex become part of your release process. A pipeline can trigger a Qodex run, wait for the result, and fail the job if scenarios fail. Use CI runs for pull-request smoke checks, pre-deploy gates, post-deploy production smoke, or scheduled policies that you want a pipeline to fire on demand.How CI triggering works
Most CI integrations follow the same shape:- Store a Qodex API key as a CI secret.
- POST to the Qodex webhook trigger endpoint.
- Read the returned
testRunId. - Poll the test run until it reaches a terminal state.
- Exit non-zero if the Qodex run failed or timed out.
Choose a trigger style
| Trigger | Use it when |
|---|---|
| Project webhook | The CI job should choose environment, tags, or callback URL dynamically. |
| Schedule webhook | The CI job should fire one preconfigured schedule. |
Provider recipes
GitHub Actions
Gate pull requests or pushes with a Qodex workflow.
GitLab CI
Add Qodex as a pipeline job for merge requests and main.
CircleCI
Trigger Qodex from a CircleCI job and fail the workflow on failure.
Buildkite
Run Qodex from a Buildkite step and gate downstream deploys.
Jenkins
Add Qodex to a declarative Jenkins pipeline.
Generic shell
Use a portable curl and jq script in any CI system.
Recommended setup
- Use one API key per CI environment, such as
github-actions-stagingorbuildkite-prod. - Store keys only in the provider’s secret store.
- Run
smokeorcriticaltags on pull requests. - Run broader
regressionor full-suite checks on main, nightly schedules, or release candidates. - Always poll to completion before marking the CI job green.
Example trigger body
environment value.
Related
Run tests via webhook
Understand the webhook API used by CI.
Run tests on a schedule
Create schedule webhooks for preconfigured runs.