@testdriverai/agent 7.11.229-canary → 7.11.231-test

package/docs/ci-cd.mdx

@@ -1,41 +1,35 @@
 ---
-title: "Integrating into CI/CD"
+title: "Run tests in CI/CD"
 sidebarTitle: "Integrating into CI/CD"
-description: "Run TestDriver tests in CI/CD with parallel execution and cross-platform support"
+description: "Run TestDriver tests on every push and pull request in GitHub Actions or any CI provider."
 icon: "code-branch"
 ---
 
-TestDriver integrates with the common CI providers. It lets you do automated end-to-end tests on each push and pull request.
+import { EnterpriseBadge, EnterpriseCta } from '/snippets/enterprise.mdx';
 
-## Authentication
+TestDriver tests are ordinary Vitest files, so any CI provider can run them with `npx vitest run`. Each test starts its own cloud sandbox, and every run is recorded in the [TestDriver console](https://console.testdriver.ai).
 
-On **GitHub Actions, use OIDC** through the published `testdriverai/action`. Then
-there is no `TD_API_KEY` secret to store, copy, or change. The action shows that the
-workflow runs in your org. TestDriver changes that proof for your
-team's key at run time. See the GitHub Actions tab below.
+You need two things in CI:
 
-For other CI providers (or self-hosted runners without OIDC), use a
-stored API key from [console.testdriver.ai/settings](https://console.testdriver.ai/settings).
-Add it as a `TD_API_KEY` secret in the settings of your CI provider.
+- **Authentication.** On GitHub Actions, use the TestDriver action with OIDC. Elsewhere, store your API key as a secret named `TD_API_KEY`.
+- **Your test command,** `npx vitest run`.
 
-<Note>
-  Never commit your API key in the code. Always use OIDC or the secrets management of your CI provider.
-</Note>
+## GitHub Actions
 
-## CI Provider Examples
+The [`testdriverai/action`](https://github.com/testdriverai/action) authenticates with GitHub's OIDC token, so you don't store an API key in GitHub. It exchanges the token for your team's key and exports `TD_API_KEY` for later steps. It doesn't run tests itself.
 
-<Tabs>
-  <Tab title="GitHub Actions">
-    ### Authenticate with OIDC via `testdriverai/action` (recommended)
+<Steps>
+  <Step title="Authorize the TestDriver GitHub app">
+
+    Install the [TestDriver GitHub app](/quickstart-github) on your organization. This links the organization to your TestDriver team. If you authorized the app before OIDC support was added, authorize it again once.
 
-    Use the published [`testdriverai/action`](https://github.com/testdriverai/action). It makes the OIDC token, changes it for your team's API key, and exports `TD_API_KEY` for the steps that come after. **There is no `TD_API_KEY` secret to store or change.**
+  </Step>
+  <Step title="Add the workflow">
 
-    <Note>
-      Do this one time: authorize the [TestDriver GitHub App](https://console.testdriver.ai) for your org. Then the org → team binding exists. If your org authorized the App before OIDC support was available, authorize it again one time. If the App is not authorized, the action fails with a console link. (Or it uses the `api-key` secret if you give one.)
-    </Note>
+    `npx testdriverai init` writes this file for you:
 
     ```yaml .github/workflows/testdriver.yml
-    name: TestDriver Tests
+    name: TestDriver tests
 
     on:
       push:
@@ -47,7 +41,7 @@ Add it as a `TD_API_KEY` secret in the settings of your CI provider.
       test:
         runs-on: ubuntu-latest
         permissions:
-          id-token: write   # REQUIRED to mint an OIDC token
+          id-token: write # lets the job mint an OIDC token
           contents: read
 
         steps:
@@ -61,260 +55,74 @@ Add it as a `TD_API_KEY` secret in the settings of your CI provider.
           - run: npm ci
 
           - name: Authenticate to TestDriver
-            uses: testdriverai/action@stable   # pin @stable / @canary / @test to your SDK channel
+            uses: testdriverai/action@stable
             with:
-              api-key: ${{ secrets.TD_API_KEY }}   # optional fallback if OIDC isn't set up
+              api-key: ${{ secrets.TD_API_KEY }} # optional fallback
 
-          - name: Run TestDriver tests
-            run: vitest run
+          - name: Run tests
+            run: npx vitest run
     ```
 
-    ### Stored-key fallback
-
-    Only if you can't use OIDC (e.g. self-hosted runners without an OIDC provider). Add the key as a secret and pass it via `env`:
-
-    1. Navigate to your GitHub repository
-    2. Go to **Settings** → **Secrets and variables** → **Actions**
-    3. Click **New repository secret**
-    4. Name: `TD_API_KEY`, Value: your API key
-    5. Click **Add secret**
+  </Step>
+</Steps>
 
-    ### Basic Workflow
+The job needs `id-token: write`, or the action can't mint the OIDC token.
 
-    Create `.github/workflows/testdriver.yml`:
+The `api-key` input is a fallback. The action uses it only when OIDC authentication fails, for example on a fork or before the app is authorized. Leave the secret unset if you don't need it.
 
-    ```yaml .github/workflows/testdriver.yml
-    name: TestDriver Tests
-
-    on:
-      push:
-        branches: [main]
-      pull_request:
-        branches: [main]
-
-    jobs:
-      test:
-        runs-on: ubuntu-latest
-        
-        steps:
-          - uses: actions/checkout@v4
-          
-          - uses: actions/setup-node@v4
-            with:
-              node-version: '20'
-              cache: 'npm'
-          
-          - run: npm ci
-          
-          - name: Run TestDriver tests
-            env:
-              TD_API_KEY: ${{ secrets.TD_API_KEY }}
-            run: vitest --run
-    ```
+<AccordionGroup>
+  <Accordion title="Action inputs">
 
-    ### Parallel Execution
+    | Input | Default | Description |
+    | --- | --- | --- |
+    | `channel` | `stable` | TestDriver release channel: `stable`, `canary`, `test`, or `dev`. Selects the API the action talks to. |
+    | `api-root` | | An explicit API URL. Overrides `channel`. |
+    | `api-key` | | A TestDriver API key to use if OIDC authentication fails. |
 
-    Use matrix strategy to run tests in parallel:
+  </Accordion>
+  <Accordion title="Use a stored key instead of OIDC">
 
-    ```yaml .github/workflows/testdriver-parallel.yml
-    name: TestDriver Tests (Parallel)
+    If OIDC isn't available, skip the action and pass the key directly:
 
-    on: [push, pull_request]
+    1. Copy an API key from the [API keys page](https://console.testdriver.ai/team/api-keys).
+    2. In your repository, go to **Settings → Secrets and variables → Actions** and add a secret named `TD_API_KEY`.
+    3. Pass it to the test step:
 
-    jobs:
-      test:
-        runs-on: ubuntu-latest
-        strategy:
-          fail-fast: false
-          matrix:
-            shard: [1, 2, 3, 4]
-        
-        steps:
-          - uses: actions/checkout@v4
-          - uses: actions/setup-node@v4
-            with:
-              node-version: '20'
-              cache: 'npm'
-          - run: npm ci
-          - name: Run tests (shard ${{ matrix.shard }}/4)
-            env:
-              TD_API_KEY: ${{ secrets.TD_API_KEY }}
-            run: vitest --run --shard=${{ matrix.shard }}/4
+    ```yaml
+    - name: Run tests
+      run: npx vitest run
+      env:
+        TD_API_KEY: ${{ secrets.TD_API_KEY }}
     ```
 
-    ### Multi-Platform Testing
+  </Accordion>
+</AccordionGroup>
 
-    ```yaml .github/workflows/testdriver-multiplatform.yml
-    name: TestDriver Tests (Multi-Platform)
+## Other CI providers
 
-    on: [push, pull_request]
+Copy an API key from the [API keys page](https://console.testdriver.ai/team/api-keys). Store it as a secret named `TD_API_KEY` in your CI provider, then use the config for your provider.
 
-    jobs:
-      test:
-        runs-on: ubuntu-latest
-        strategy:
-          fail-fast: false
-          matrix:
-            td-os: [linux, windows]
-        
-        steps:
-          - uses: actions/checkout@v4
-          - uses: actions/setup-node@v4
-            with:
-              node-version: '20'
-              cache: 'npm'
-          - run: npm ci
-          - name: Run tests on ${{ matrix.td-os }}
-            env:
-              TD_API_KEY: ${{ secrets.TD_API_KEY }}
-              TD_OS: ${{ matrix.td-os }}
-            run: vitest --run
-    ```
-  </Tab>
+<Warning>
+  Never commit your API key to the repository. Keep it in your CI provider's secret store.
+</Warning>
 
+<Tabs>
   <Tab title="GitLab CI">
-    ### Adding Secrets
-    
-    1. Go to your GitLab project
-    2. Navigate to **Settings** → **CI/CD** → **Variables**
-    3. Click **Add variable**
-    4. Key: `TD_API_KEY`, Value: your API key
-    5. Check **Mask variable** and click **Add variable**
 
-    ### Basic Pipeline
-
-    Create `.gitlab-ci.yml`:
+    Add `TD_API_KEY` under **Settings → CI/CD → Variables**, with **Mask variable** checked. GitLab exposes project variables to every job.
 
     ```yaml .gitlab-ci.yml
-    stages:
-      - test
-
     testdriver:
-      stage: test
       image: node:20
-      cache:
-        paths:
-          - node_modules/
       script:
         - npm ci
-        - vitest --run
-      variables:
-        TD_API_KEY: $TD_API_KEY
-    ```
-
-    ### Parallel Execution
-
-    ```yaml .gitlab-ci.yml
-    stages:
-      - test
-
-    .testdriver-base:
-      stage: test
-      image: node:20
-      cache:
-        paths:
-          - node_modules/
-      before_script:
-        - npm ci
-      variables:
-        TD_API_KEY: $TD_API_KEY
-
-    testdriver-shard-1:
-      extends: .testdriver-base
-      script:
-        - vitest --run --shard=1/4
-
-    testdriver-shard-2:
-      extends: .testdriver-base
-      script:
-        - vitest --run --shard=2/4
-
-    testdriver-shard-3:
-      extends: .testdriver-base
-      script:
-        - vitest --run --shard=3/4
-
-    testdriver-shard-4:
-      extends: .testdriver-base
-      script:
-        - vitest --run --shard=4/4
+        - npx vitest run
     ```
 
-    ### Multi-Platform Testing
-
-    ```yaml .gitlab-ci.yml
-    stages:
-      - test
-
-    .testdriver-base:
-      stage: test
-      image: node:20
-      cache:
-        paths:
-          - node_modules/
-      before_script:
-        - npm ci
-      variables:
-        TD_API_KEY: $TD_API_KEY
-
-    testdriver-linux:
-      extends: .testdriver-base
-      variables:
-        TD_OS: linux
-      script:
-        - vitest --run
-
-    testdriver-windows:
-      extends: .testdriver-base
-      variables:
-        TD_OS: windows
-      script:
-        - vitest --run
-    ```
   </Tab>
-
   <Tab title="CircleCI">
-    ### Adding Secrets
-    
-    1. Go to your CircleCI project
-    2. Click **Project Settings** → **Environment Variables**
-    3. Click **Add Environment Variable**
-    4. Name: `TD_API_KEY`, Value: your API key
-
-    ### Basic Config
-
-    Create `.circleci/config.yml`:
-
-    ```yaml .circleci/config.yml
-    version: 2.1
-
-    jobs:
-      test:
-        docker:
-          - image: cimg/node:20.0
-        steps:
-          - checkout
-          - restore_cache:
-              keys:
-                - npm-deps-{{ checksum "package-lock.json" }}
-          - run: npm ci
-          - save_cache:
-              key: npm-deps-{{ checksum "package-lock.json" }}
-              paths:
-                - node_modules
-          - run:
-              name: Run TestDriver tests
-              command: vitest --run
-              environment:
-                TD_API_KEY: ${TD_API_KEY}
-
-    workflows:
-      test:
-        jobs:
-          - test
-    ```
 
-    ### Parallel Execution
+    Add `TD_API_KEY` under **Project Settings → Environment Variables**. CircleCI exposes project variables to every job.
 
     ```yaml .circleci/config.yml
     version: 2.1
@@ -322,24 +130,11 @@ Add it as a `TD_API_KEY` secret in the settings of your CI provider.
     jobs:
       test:
         docker:
-          - image: cimg/node:20.0
-        parallelism: 4
+          - image: cimg/node:lts
         steps:
           - checkout
-          - restore_cache:
-              keys:
-                - npm-deps-{{ checksum "package-lock.json" }}
           - run: npm ci
-          - save_cache:
-              key: npm-deps-{{ checksum "package-lock.json" }}
-              paths:
-                - node_modules
-          - run:
-              name: Run TestDriver tests
-              command: |
-                vitest --run --shard=$((CIRCLE_NODE_INDEX + 1))/$CIRCLE_NODE_TOTAL
-              environment:
-                TD_API_KEY: ${TD_API_KEY}
+          - run: npx vitest run
 
     workflows:
       test:
@@ -347,92 +142,17 @@ Add it as a `TD_API_KEY` secret in the settings of your CI provider.
           - test
     ```
 
-    ### Multi-Platform Testing
-
-    ```yaml .circleci/config.yml
-    version: 2.1
-
-    jobs:
-      test:
-        docker:
-          - image: cimg/node:20.0
-        parameters:
-          td-os:
-            type: string
-        steps:
-          - checkout
-          - run: npm ci
-          - run:
-              name: Run TestDriver tests on << parameters.td-os >>
-              command: vitest --run
-              environment:
-                TD_API_KEY: ${TD_API_KEY}
-                TD_OS: << parameters.td-os >>
-
-    workflows:
-      test:
-        jobs:
-          - test:
-              td-os: linux
-          - test:
-              td-os: windows
-    ```
   </Tab>
-
   <Tab title="Azure Pipelines">
-    ### Adding Secrets
-    
-    1. Go to your Azure DevOps project
-    2. Navigate to **Pipelines** → **Library** → **Variable groups**
-    3. Create a new variable group or edit existing
-    4. Add variable: `TD_API_KEY` with your API key
-    5. Click the lock icon to make it secret
-
-    ### Basic Pipeline
-
-    Create `azure-pipelines.yml`:
-
-    ```yaml azure-pipelines.yml
-    trigger:
-      - main
-
-    pool:
-      vmImage: 'ubuntu-latest'
-
-    steps:
-      - task: NodeTool@0
-        inputs:
-          versionSpec: '20.x'
-        displayName: 'Setup Node.js'
 
-      - script: npm ci
-        displayName: 'Install dependencies'
-
-      - script: vitest --run
-        displayName: 'Run TestDriver tests'
-        env:
-          TD_API_KEY: $(TD_API_KEY)
-    ```
-
-    ### Parallel Execution
+    Add `TD_API_KEY` as a pipeline variable and mark it secret. Azure doesn't expose secret variables to scripts automatically, so map it with `env`.
 
     ```yaml azure-pipelines.yml
     trigger:
       - main
 
     pool:
-      vmImage: 'ubuntu-latest'
-
-    strategy:
-      matrix:
-        shard1:
-          SHARD: '1/4'
-        shard2:
-          SHARD: '2/4'
-        shard3:
-          SHARD: '3/4'
-        shard4:
-          SHARD: '4/4'
+      vmImage: ubuntu-latest
 
     steps:
       - task: NodeTool@0
@@ -440,248 +160,139 @@ Add it as a `TD_API_KEY` secret in the settings of your CI provider.
           versionSpec: '20.x'
 
       - script: npm ci
-        displayName: 'Install dependencies'
+        displayName: Install dependencies
 
-      - script: vitest --run --shard=$(SHARD)
-        displayName: 'Run TestDriver tests'
+      - script: npx vitest run
+        displayName: Run TestDriver tests
         env:
           TD_API_KEY: $(TD_API_KEY)
     ```
 
-    ### Multi-Platform Testing
-
-    ```yaml azure-pipelines.yml
-    trigger:
-      - main
-
-    pool:
-      vmImage: 'ubuntu-latest'
-
-    strategy:
-      matrix:
-        linux:
-          TD_OS: 'linux'
-        windows:
-          TD_OS: 'windows'
-
-    steps:
-      - task: NodeTool@0
-        inputs:
-          versionSpec: '20.x'
-
-      - script: npm ci
-        displayName: 'Install dependencies'
-
-      - script: vitest --run
-        displayName: 'Run TestDriver tests on $(TD_OS)'
-        env:
-          TD_API_KEY: $(TD_API_KEY)
-          TD_OS: $(TD_OS)
-    ```
   </Tab>
-
   <Tab title="Jenkins">
-    ### Adding Secrets
-    
-    1. Go to **Manage Jenkins** → **Credentials**
-    2. Select the appropriate domain
-    3. Click **Add Credentials**
-    4. Kind: **Secret text**
-    5. ID: `td-api-key`, Secret: your API key
-
-    ### Basic Pipeline
 
-    Create `Jenkinsfile`:
+    Add a **Secret text** credential with the ID `td-api-key` under **Manage Jenkins → Credentials**.
 
     ```groovy Jenkinsfile
     pipeline {
-        agent {
-            docker {
-                image 'node:20'
-            }
-        }
-        
+        agent { docker { image 'node:20' } }
+
         environment {
             TD_API_KEY = credentials('td-api-key')
         }
-        
+
         stages {
-            stage('Install') {
-                steps {
-                    sh 'npm ci'
-                }
-            }
-            
             stage('Test') {
                 steps {
-                    sh 'vitest --run'
+                    sh 'npm ci'
+                    sh 'npx vitest run'
                 }
             }
         }
     }
     ```
 
-    ### Parallel Execution
+  </Tab>
+</Tabs>
 
-    ```groovy Jenkinsfile
-    pipeline {
-        agent none
-        
-        environment {
-            TD_API_KEY = credentials('td-api-key')
-        }
-        
-        stages {
-            stage('Test') {
-                parallel {
-                    stage('Shard 1') {
-                        agent { docker { image 'node:20' } }
-                        steps {
-                            sh 'npm ci'
-                            sh 'vitest --run --shard=1/4'
-                        }
-                    }
-                    stage('Shard 2') {
-                        agent { docker { image 'node:20' } }
-                        steps {
-                            sh 'npm ci'
-                            sh 'vitest --run --shard=2/4'
-                        }
-                    }
-                    stage('Shard 3') {
-                        agent { docker { image 'node:20' } }
-                        steps {
-                            sh 'npm ci'
-                            sh 'vitest --run --shard=3/4'
-                        }
-                    }
-                    stage('Shard 4') {
-                        agent { docker { image 'node:20' } }
-                        steps {
-                            sh 'npm ci'
-                            sh 'vitest --run --shard=4/4'
-                        }
-                    }
-                }
-            }
-        }
-    }
-    ```
+## Split tests across jobs
 
-    ### Multi-Platform Testing
+Vitest runs test files in parallel within one job. To spread a large suite across several jobs, use Vitest's `--shard` flag:
 
-    ```groovy Jenkinsfile
-    pipeline {
-        agent none
-        
-        environment {
-            TD_API_KEY = credentials('td-api-key')
-        }
-        
-        stages {
-            stage('Test') {
-                parallel {
-                    stage('Linux') {
-                        agent { docker { image 'node:20' } }
-                        environment {
-                            TD_OS = 'linux'
-                        }
-                        steps {
-                            sh 'npm ci'
-                            sh 'vitest --run'
-                        }
-                    }
-                    stage('Windows') {
-                        agent { docker { image 'node:20' } }
-                        environment {
-                            TD_OS = 'windows'
-                        }
-                        steps {
-                            sh 'npm ci'
-                            sh 'vitest --run'
-                        }
-                    }
-                }
-            }
-        }
-    }
-    ```
-  </Tab>
-</Tabs>
+```yaml .github/workflows/testdriver.yml
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    permissions:
+      id-token: write
+      contents: read
+    strategy:
+      fail-fast: false
+      matrix:
+        shard: [1, 2, 3, 4]
 
-## Reading Platform in Tests
-
-When using multi-platform testing, read the `TD_OS` environment variable in your test:
-
-```javascript tests/cross-platform.test.mjs
-import { describe, expect, it } from "vitest";
-import { TestDriver } from "testdriverai/vitest/hooks";
-
-describe("Cross-platform tests", () => {
-  it("should work on both Linux and Windows", async (context) => {
-    const os = process.env.TD_OS || 'linux';
-    
-    const testdriver = TestDriver(context, { 
-      os: os  // 'linux' or 'windows'
-    });
-    
-    await testdriver.provision.chrome({
-      url: 'https://example.com',
-    });
-
-    const result = await testdriver.assert("the page loaded successfully");
-    expect(result).toBeTruthy();
-  });
-});
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          cache: 'npm'
+      - run: npm ci
+      - uses: testdriverai/action@stable
+      - run: npx vitest run --shard=${{ matrix.shard }}/4
 ```
 
-## Concurrency limits
+Other providers work the same way. Run `npx vitest run --shard=<index>/<total>` in each parallel job.
+
+## Run on Linux and Windows
 
-Your plan allows a fixed number of sandboxes running at once. When a test asks for
-a sandbox and you're already at that limit, the request is **queued** rather than
-failed immediately: the SDK waits for a slot to free up, retrying every 10 seconds,
-then proceeds automatically once one opens. This is what lets a parallel CI matrix
-(many jobs starting at once) work on a plan with fewer slots than jobs — the extra
-jobs simply wait their turn instead of erroring.
+Set `TD_OS` to choose the sandbox's operating system. TestDriver reads it when it creates the sandbox, so your tests don't need any changes:
 
-By default the SDK waits up to **60 seconds** for a slot before giving up with a
-concurrency-limit error. Control that ceiling with `TD_CONCURRENCY_MAX_WAIT`:
+```yaml
+strategy:
+  fail-fast: false
+  matrix:
+    td-os: [linux, windows]
+
+steps:
+  # ...checkout, setup-node, npm ci, testdriverai/action
+  - run: npx vitest run
+    env:
+      TD_OS: ${{ matrix.td-os }}
+```
+
+Linux is the default.
+
+<EnterpriseCta feature="Windows sandboxes" plural />
 
-| Value | Behavior |
-| ----- | -------- |
-| _unset_ | Wait up to **60 seconds** (the default). |
-| `TD_CONCURRENCY_MAX_WAIT=300` | Wait up to **300 seconds** (5 minutes) before giving up. |
-| `TD_CONCURRENCY_MAX_WAIT=0` | **Don't queue** — fail on the first denial. |
+An `os` option passed to `TestDriver()` takes priority over `TD_OS`. To branch on the platform inside a test, read `process.env.TD_OS`:
 
-The value is **in seconds** (fractional values are allowed and rounded to the
-nearest millisecond). Any invalid or negative value falls back to the 60-second
-default. The wait applies per sandbox request, across both the initial allocation
-and the realtime slot-approval handshake.
+```javascript
+const isWindows = process.env.TD_OS === 'windows';
+
+await testdriver.exec({
+  language: isWindows ? 'pwsh' : 'sh',
+  code: isWindows ? 'Get-ChildItem $HOME' : 'ls ~',
+});
+```
+
+## Concurrency limits
+
+Your plan sets how many sandboxes can run at once. When a job asks for a sandbox at that limit, it waits for a free slot instead of failing.
+
+- The SDK retries every 10 seconds.
+- By default, it gives up after 60 seconds with a concurrency-limit error.
+- Set `TD_CONCURRENCY_MAX_WAIT` (in seconds) to wait longer, or to `0` to fail on the first refusal.
 
 ```yaml
-# Example: a large parallel matrix that may queue for a while.
-# Give each job up to 5 minutes to acquire a slot before failing.
-- name: Run TestDriver tests
+- run: npx vitest run
   env:
-    TD_API_KEY: ${{ secrets.TD_API_KEY }}
-    TD_CONCURRENCY_MAX_WAIT: "300"
-  run: vitest run
+    TD_CONCURRENCY_MAX_WAIT: '300' # wait up to 5 minutes for a slot
 ```
 
-<Tip>
-Raise `TD_CONCURRENCY_MAX_WAIT` when you run more parallel jobs than your plan has
-slots and would rather they queue than fail. Set it to `0` when you'd prefer a job
-to **fail fast** on a busy account (e.g. a quick smoke test that shouldn't sit
-waiting). When jobs routinely give up waiting, that's the signal to
-[add more slots](https://console.testdriver.ai/checkout/pro).
-</Tip>
+Raise the wait when you run more parallel jobs than your plan has slots. If jobs regularly give up waiting, run fewer at once with `--maxWorkers` or add slots to your plan.
+
+## View results
 
-## Viewing Results
+Each run is recorded in the [TestDriver console](https://console.testdriver.ai), with a video replay, logs, and pass or fail status. When a run finishes, the SDK prints a link to it:
 
-All test runs are automatically recorded and visible in your TestDriver dashboard at [console.testdriver.ai](https://console.testdriver.ai):
+```text
+TESTDRIVER_RUN_URL=https://console.testdriver.ai/runs/abc123
+```
 
-- All test runs with pass/fail status
-- Video replays of each test
-- Error messages and screenshots on failure
-- Git commit and branch information
-- Duration trends over time
+## Next steps
+
+<CardGroup cols={2}>
+  <Card title="Run tests" icon="play" href="/copilot/running-tests">
+    Run tests locally, in parallel, and watch them live.
+  </Card>
+  <Card title="Add TestDriver to GitHub" icon="github" href="/quickstart-github">
+    Get an AI code review on every pull request.
+  </Card>
+  <Card title="Hosted plans" icon="cloud" href="/hosted">
+    Compare plans, testing minutes, and concurrency.
+  </Card>
+  <Card title="Speed up reruns with caching" icon="brain" href="/caching">
+    Reuse element locations from passing runs.
+  </Card>
+</CardGroup>