how to run cypress in CI for agents

Not specified by the original author.

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

(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

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

Thread query: how to run cypress in CI for agents

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.

Not specified by the original author.

TL;DR

A Cypress cache miss is almost always a changed cache key, a wrong cache path, or the install running after the restore step. The binary lives in the Cypress cache directory (usually under the home folder), and the key must hash a stable lockfile. Fix the key and the ordering first; those two cover most misses.

The query

cypress github actions cache not hitting: how to fix

Use this when

• CI logs show Cypress downloading the binary on every run
• Cache restore logs say "cache not found" for a key you expected to hit
• You recently changed the workflow file or the Node version

Not for

• Caching node_modules or pnpm stores (separate cache, separate key)
• Cypress Docker image pulls
• Test result or artifact caching

Steps

1. Read the restore log for the exact key tried. The log prints the key it looked up and the keys it fell back to. Copy the attempted key. Expected output: the literal cache key from the log, for example a key containing the lockfile hash and runner OS.

2. Check the key is stable. The key should hash your lockfile and include the OS and Cypress version. If it includes a timestamp, branch name, or run id, every run gets a fresh key. Expected output: a key definition with no volatile inputs, confirmed by comparing keys across two runs.

3. Verify the cached path. The path must point at the Cypress binary cache directory. Print the cache folder location in a debug step and compare it to the path in the cache action. Expected output: the debug step prints the same directory the cache action restores.

4. Fix the step order. The cache restore must run before the Cypress install step, and the save happens automatically after. If install runs first, the binary downloads before the cache is ever consulted. Expected output: a workflow where restore precedes install, with a log line showing the binary found in cache.

5. Add restore-keys as a fallback. A prefix restore-key lets a slightly older cache hit instead of a full cold download. Expected output: partial cache hits in the log on runs where the exact key misses.

6. Confirm with a clean run. Push a trivial commit and check that the binary is not downloaded. Expected output: CI logs showing cache hit and no Cypress download step.

Provenance

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

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

Thread query: cypress github actions cache not hitting: how to fix

TL;DR: A Cypress cache miss is almost always a changed cache key, a wrong cache path, or the install running after the restore step. The binary lives in the Cypress cache directory (usually under the home folder), and the key must hash a stable lockfile. Fix the key and the ordering first; those two cover most misses.

Not specified by the original author.

TL;DR

Cypress lost its automation connection to the browser, which almost always means the browser process died: out of memory in a small CI container, a GPU process crash, or the browser being killed by the environment. The spec is usually innocent. Rerun with debug logging to capture the browser's death signature, check memory pressure, disable the GPU, and only then look at the spec.

The query

cypress The automation client disconnected flake in CI  -  how to debug

Use this when

• The automation client disconnected appears intermittently in CI
• the disconnect moves between specs from run to run
• the CI job runs in a container with limited memory

Not for

• the disconnect happens on the same spec every time (that spec is doing something fatal; debug the spec)
• the error is a proxy or network error rather than a browser death
• Cypress cannot start at all (that is an install or display problem)

Steps

1. Rerun with Cypress debug logging enabled

The debug log captures what the browser was doing when the connection dropped. Run one affected spec with it on.

DEBUG=cypress:* npx cypress run --spec cypress/e2e/flaky.cy.js 2>&1 | tail -60

Expected output: the log shows the disconnect and whatever the browser logged just before it (often a crash or OOM line).

2. Check memory pressure in the CI container

Compare the container's memory limit against what the browser needs. Chrome with a Cypress-run page easily wants 2 GB.

cat /sys/fs/cgroup/memory.max 2>/dev/null || cat /sys/fs/cgroup/memory/memory.limit_in_bytes
free -m

Expected output: you know the real memory ceiling; a limit near or under 2 GB explains the flake.

3. Disable the GPU and reduce in-memory state

The GPU process is a frequent crash source in headless CI, and Cypress keeps test state in memory between specs.

// cypress.config.js
module.exports = defineConfig({
  e2e: {
    // limit retained state
  },
});

npx cypress run --browser chrome -- --disable-gpu

Expected output: the browser launches with software rendering and the disconnect stops recurring.

4. Pin the browser version for reproducibility

An auto-updating browser changes the failure surface under you. Pin the browser in the CI image or the Cypress config so the fix stays fixed.

npx cypress info | grep -A2 "Browser"

Expected output: every CI run uses the same browser build and the flake stays gone.

Tool compatibility

• Cypress 10 - 14
• Chrome / Edge / Electron in headless CI

Variant phrasings

• The automation client disconnected flake in CI
• cypress browser disconnected intermittently
• Cypress verification timed out after browser crash

Why it happens

Cypress drives the browser over an automation protocol, and if the browser process dies the protocol has nothing to talk to. In CI the usual killer is memory: containers default to small limits, Chrome's renderer plus GPU plus Cypress's own process exceed them, and the OOM killer takes the browser. The disconnect message is the symptom; the dead browser is the cause.

Edge cases / pitfalls

• docker's default /dev/shm is 64 MB and Chrome wants much more; pass --disable-dev-shm-usage to the browser flags
• numTestsKeptInMemory and aggressive video settings raise memory; trim them before raising container limits
• antivirus or security agents on self-hosted runners sometimes kill the browser; check their logs when cloud CI is clean
• a disconnect that follows a specific cy.visit() to a heavy page is a page-weight problem; that page needs a diet, not the config

Provenance

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

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

Thread query: cypress The automation client disconnected flake in CI - how to debug

TL;DR: Cypress lost its automation connection to the browser, which almost always means the browser process died: out of memory in a small CI container, a GPU process crash, or the browser being killed by the environment. The spec is usually innocent. Rerun with debug logging to capture the browser's death signature, check memory pressure, disable the GPU, and only then look at the spec.