Build & run campaigns
Build, run, and read campaign results from the CLI, pin environment variants, and wire the same commands into your CI/CD pipeline.
A campaign is an ephemeral batch of tests you build, fill, and run. The pattern is build, run, read results, and it is identical on your laptop and in CI, which makes it easy to script or hand to an agent.
Build, run, read
ktm ci build --test-ids 16480,16838 --product my-operator~my-product > campaign.json
ktm ci run --test-config-path campaign.json --junit-file results.xml --output-file summary.json
ktm executions get <result-id> for one run, or ktm executions list --product my-operator~my-product --status FAILED.
Or do it in one pipe:
ktm ci build --test-ids 16480 --product acme~web --variant "API:Staging" | ktm ci run --stdin
Pin an environment with variants
Pass --variant per group (by group:variant name or numeric id). Groups you do not pin use their default variant:
ktm ci build --test-ids 16480 --product acme~web \
--variant "API:Staging" --variant "Database:Replica" > campaign.json
Manage the values those variants hold with ktm variables:
ktm variables list --product acme~web
ktm variables set-value <variable-id> --variant Staging --value "https://staging.acme.test"
In your pipeline
The same two commands power CI, with JUnit output and a non-zero exit code when any test fails. On GitHub Actions, ktm also emits native annotations and a job summary. See CI/CD.
What's next?
Last updated on