Robusty

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:

  1. Open your project's Settings, find the Tokens card.
  2. Click Create token, give it a Name (for example GitHub Actions) and an expiry (7, 30, 90 days, or never).
  3. 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:

.github/workflows/robusty.yml
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:

.gitlab-ci.yml
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:

.github/workflows/robusty.yml
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?

On this page