TestKase
TestKase
|Docs
Organization & AccountIntegrationsCI/CD

CI/CD

Run your Automate tests from Jenkins, GitHub Actions, GitLab CI, CircleCI, Azure Pipelines or Bitbucket Pipelines — what changes, and the exact snippet for each.

What this is

Your Automate tests already connect to TestKase from the test code and its testkase.yml. A CI pipeline just runs that same code on every push instead of you running it on your laptop — nothing about the connection changes.

Organization → Integrations → CI/CD is the setup helper for that move. It isn't a connection and stores nothing; it gives you a copy-paste job for your CI tool with the three things that do change already filled in.

The three things that change

  1. The access key leaves your laptop. In CI it lives in the tool's secret store and the tests read it from an environment variable — never from a file in the repository.
  2. Runs get a build name. Set build to the pipeline's run number so the dashboard groups sessions as run #57, run #58 instead of one anonymous pile. Every CI tool names that number differently; the snippets use the right one.
  3. Staging URLs need a tunnel. If the tests open an address the device farm can't reach (staging.internal, localhost), the pipeline starts testkase-tunnel first.

Credentials

  • Username — the email you sign in with.
  • Access key — a personal access token from Settings → API Keys (how). Store it in your CI tool's secret store as TESTKASE_ACCESS_KEY; the snippets read it from there into ACCESS_KEY.

The runner reads two environment variables: TK_USERNAME and ACCESS_KEY. Remove them from testkase.yml when you commit it — the file falls back to the variables when the keys are absent.

Per-tool snippets

Each page has a complete job, in three tabs — Playwright, Selenium, Appium (mobile) — with the tool's run-id variable and where its secrets live. Playwright runs through the testkase-playwright wrapper; Selenium and Appium have no wrapper and keep running your existing test command, reading TK_USERNAME / ACCESS_KEY the same way they already do outside CI.

Recording results in Test Management

Optional. If you also want each pipeline run recorded as an execution in Test Management, add one step after the tests:

npx @testkase/reporter report \
  --token "$ACCESS_KEY" \
  --org-id <ORG_ID> \
  --project-id <PROJECT_ID> \
  --format junit \
  --results-file results.xml

See Test Management → Automation for the reporter.

The snippets are for Automate. Live and Accessibility are used interactively in the browser and have nothing to put in a pipeline.