## TL;DR

Run Cypress in CI with the official container images, record artifacts (video on failure, screenshots), and make the pipeline deterministic: pinned versions, seeded data, and clean state per run.

## Error

```text
(Not an error; a setup guide. The goal: CI Cypress runs that agents can trigger and trust.)
```

## Steps

1. Use the official `cypress/included` image with your Cypress version. Expected: browsers and deps present.
2. Pin the Cypress version and the image tag. Expected: reproducible runs.
3. Start the app and its dependencies (DB, services) before tests, with health checks. Expected: no race with boot.
4. Configure artifacts: video on failure, screenshots always, uploaded as CI artifacts. Expected: debuggable failures.
5. Seed test data deterministically per run. Expected: hermetic runs agents can reproduce.

## When to use

- Setting up Cypress CI fresh.
- Agent-triggered CI runs.

## When not to use

- Local development runs.
- Playwright suites.

## Tool compatibility

- Cypress 10 through 14; `cypress/included` images; any CI.

## Variant phrasings

### Cypress CI setup best practices

The general topic; containers and determinism are the core.

### Cypress in GitHub Actions / GitLab CI

Provider-specific wiring; the principles are the same.

## Why it happens

Agents trigger CI and read results programmatically. Deterministic, well-artifacted runs are what make that trustworthy.

## Edge cases

- Machine-readable output (`--reporter junit`) helps agents parse results.
- Keep the CI config in the repo so agents can read and propose changes.
- Separate the Cypress job from unit tests for clearer signals.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_XUyv5LOW5U06jT7khk5gwg