CI/CD integration
Run Robusty in your pipeline as a quality gate.
Run a test suite from your CI/CD pipeline with the
CLI and let it gate deploys. robusty launch streams the agent's
progress and exits non-zero when a test case fails, so a failing launch fails the
job — the same quality gate you get from the dashboard, wired into your pipeline.
In CI you don't run robusty login or robusty link. Instead you authenticate
with a project token and target the suite directly.
Create a project token
A project token is a project-scoped credential (prefix rbst_) that authenticates
the CLI without an interactive login. Create one in the dashboard:
- Open your project's Settings, find the Tokens card.
- Click Create token, give it a Name (for example
GitHub Actions) and an expiry (7, 30, 90 days, or never). - Copy the token when it's shown. For security it's displayed once and cannot be viewed again.
Only project admins can create tokens. Store the token as a secret in your CI provider — never commit it to the repository.
A project token has admin-equivalent access to its project. Keep it in your CI provider's secret store, scope its expiry, and revoke it from the Tokens card if it leaks.
Authenticate with the token
Expose the token as the ROBUSTY_TOKEN environment variable. When it's set, the
CLI targets the token's project directly — no login, no link:
export ROBUSTY_TOKEN=rbst_...
robusty launch --suite <suite-id>Find the suite ID in the suite's settings in the dashboard. The command streams progress and exits non-zero if any test case fails.
Gate pull requests and releases
Run the suite whenever code lands on main (or before a release). The failing
exit code fails the pipeline, so a regression never reaches your users unnoticed.
Adjust the trigger to gate other events — pull/merge requests, tags, or manual
runs.
GitHub Actions
Store the token as a repository secret (Settings → Secrets and variables →
Actions), then reference it as ROBUSTY_TOKEN:
name: Robusty
on:
push:
branches:
- main
jobs:
quality-gate:
runs-on: ubuntu-latest
steps:
- uses: actions/setup-node@v4
with:
node-version: 22
- name: Run Robusty suite
env:
ROBUSTY_TOKEN: ${{ secrets.ROBUSTY_TOKEN }}
run: npx @robusty/cli launch --suite <suite-id>The job fails when the launch exits non-zero.
GitLab CI
Add the token as a masked CI/CD variable
named ROBUSTY_TOKEN (Settings → CI/CD → Variables). It's then available to
the job automatically:
robusty:
image: node:22
rules:
- if: $CI_COMMIT_BRANCH == "main"
script:
- npx @robusty/cli launch --suite <suite-id>Test a dynamic deployment URL
Most pipelines build a fresh preview URL per branch, so the target changes on
every run. Override {{PROJECT_URL}} with --var at launch time to point the
suite at that deployment — no need to hardcode an environment. Have the deploy
step emit its URL as an output and pass it to the launch:
jobs:
deploy:
runs-on: ubuntu-latest
outputs:
url: ${{ steps.deploy.outputs.url }}
steps:
- uses: actions/checkout@v4
- id: deploy
uses: ./actions/deploy
robusty:
needs: deploy
runs-on: ubuntu-latest
steps:
- uses: actions/setup-node@v4
with:
node-version: 22
- env:
ROBUSTY_TOKEN: ${{ secrets.ROBUSTY_TOKEN }}
run: |
npx @robusty/cli launch --suite <suite-id> \
--var PROJECT_URL=${{ needs.deploy.outputs.url }}See overriding variables for the full picture.
Every CI launch counts against your project's monthly run quota, the same as a manual or scheduled run.
How is this guide?
