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

1
Build a campaign template

ktm ci build --test-ids 16480,16838 --product my-operator~my-product > campaign.json

2
Run it

ktm ci run --test-config-path campaign.json --junit-file results.xml --output-file summary.json

3
Read results

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?

CI/CD

Wire build and run into your pipeline.

Monitors & incidents

Run tests on a schedule and react to failures.

Last updated on