Custom setups
No dedicated page for your CI provider? It doesn't matter. The shiplight CLI runs on any pipeline that has Node — Drone, Woodpecker, TeamCity, Bitbucket Pipelines, a bare shell script, or anything else. The provider-specific pages are just this same recipe in each provider's syntax.
The recipe
Any provider needs four things, in order:
npm install # installs the shiplight CLI (shiplightai) + project deps
npx playwright install --with-deps chromium # the browser the tests drive (drop --with-deps if the image has the libs)
npx shiplight test # run the tests
npx shiplight report # upload results — must run even when tests failAnd two environment variables:
| Variable | Value | Why |
|---|---|---|
SHIPLIGHT_API_TOKEN | org token from app.shiplight.ai/api-tokens | authenticates the upload (report), and LLM-proxy calls for AI-powered test steps; store it as a secret |
SHIPLIGHT_REPORT_TO_CLOUD | 1 | enables the cloud upload |
Making report always run
The upload has to happen even when tests fail, or a red run produces no cloud report. Use whatever "run regardless" mechanism your provider offers — a post/after hook, when: always, or capture-and-re-exit in a shell script:
set +e
npx shiplight test; STATUS=$?
npx shiplight report
exit $STATUSWhat you don't get off GitHub Actions
Shiplight-hosted runners, the self-healing action cache, automatic LLM credentials, and the failure auto-triage pipeline are all GitHub Actions only. On a custom provider you supply the token, install Chromium, and — if your tests use AI-powered actions — provide your own LLM credentials as environment variables.
Notes
- Project in a subdirectory (e.g.
tests/e2e)?cdinto it before each command. - Tests that use AI-powered actions (natural-language steps, self-healing locators) need LLM credentials in the job env; only Shiplight runners provide these automatically.