cypress-grep only running tagged tests locally: how to fix

Not specified by the original author.

TL;DR

A grep filter set in your local environment (env var, env file, or CLI history) persists and filters every local run. Find where the filter is defined, clear it for local runs, and keep the CI filtering where it belongs. Local runs then execute the full suite.

Error

cypress-grep only running tagged tests locally: how to fix

Local cypress run executes only @smoke tagged tests; the same command in CI runs everything.

Steps

1. Check for the env var in your shell: look for CYPRESS_GREP or grep config in your shell profile. Expected output: you find the persistent filter or rule it out.
2. Check cypress.env.json and cypress.config for a grep or filter spec setting. Expected output: you know whether the config itself filters.
3. Clear the local filter: unset the env var for the session and remove it from the shell profile if it does not belong there. Expected output: the variable is gone from the local environment.
4. Keep CI filtering intact: ensure the CI job still sets the grep var it needs. Expected output: CI behavior unchanged.
5. Run the suite locally with no grep flags. Expected output: all tests run, not just tagged ones.

When to use

• Local runs execute only tagged tests.
• CI runs the full suite but local does not (or vice versa).
• You inherited a machine or dotfiles with the filter set.

When not to use

• You want grep filtering locally too (then it is working as intended).
• CI also runs only tagged tests (the filter is in shared config; move it).
• Tags are not recognized at all (that is a cypress-grep setup issue).

Variant phrasings

Grep tags work in CI but empty locally

The CI job sets the tag filter the local run lacks, or vice versa; diff the two environments' env.

Exclude-specs-filter interplay

cypress-grep and excludeSpecs can combine to an empty set; check both when nothing runs.

cypress-grep with --spec

A --spec file list plus a grep filter narrows twice; drop one when debugging.

Why it happens

cypress-grep reads its filter from the environment and config at startup, and shells persist env vars across sessions. A filter set once for a focused CI job or a debugging session keeps applying to every later local run until it is cleared.

Edge cases

• Some wrappers set CYPRESS_GREP in npm scripts; check package.json scripts, not just the shell.
• Clearing the var in one terminal does not clear it in the IDE's integrated terminal; check both.
• A filter that matches nothing produces a green run with zero tests; treat empty runs as suspicious.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_j6dvi45ysBLa-5CwCykONA

Resolved from the public thread: https://vectle.com/posts/pst_j6dvi45ysBLa-5CwCykONA

Thread query: cypress-grep only running tagged tests locally: how to fix

TL;DR: A grep filter set in your local environment (env var, env file, or CLI history) persists and filters every local run. Find where the filter is defined, clear it for local runs, and keep the CI filtering where it belongs. Local runs then execute the full suite.

Not specified by the original author.

TL;DR

CI-only failures come from environment differences, not from the tests being wrong. Diff the environments systematically: base URL, test data, parallelism, viewport, and browser version, then reproduce the CI conditions locally with the same container image.

Error

Cypress run exits with code 1 in CI; the same spec passes with `cypress open` locally.
(No single error string; the failing spec varies run to run.)

Steps

1. Run the exact CI command locally, including the same browser in headless mode: npx cypress run --browser chrome. Expected: reproduces some CI-only failures immediately.
2. Run inside the CI container image locally with docker. Expected: eliminates "works on my machine" environment drift.
3. Check for parallelism issues: run the failing spec alone in CI (--spec). Expected: if it passes alone, the cause is cross-spec interference (shared DB, ports, files).
4. Compare test data URIs CI often seeds a different dataset. Dump the seed counts in both environments. Expected: row counts match; if not, the seed step differs.
5. Check the browser version Cypress used in CI logs versus local. Expected: identical major versions; a mismatch explains rendering and timing differences.

When to use

• Green locally, red in CI, with no code change between the two.
• Failures move between specs from run to run.

When not to use

• The failure reproduces locally (debug it locally; faster).
• CI fails at install or verify time (environment setup issue).

Tool compatibility

• Cypress 10 through 14; any CI provider; docker for local reproduction.

Variant phrasings

Cypress passes headed but fails headless

Headless rendering and timing differ; treat as an environment difference, not a test bug.

Cypress fails only with --record --parallel

Parallel runners share state; look for cross-spec interference.

Why it happens

Local and CI differ in CPU count, memory, screen size, fonts, timezone, seeded data, and network speed. Tests that depend on any of these implicitly fail only where the assumption breaks.

Edge cases

• Timezone differences break date-sensitive tests; pin TZ in CI and locally.
• Font rendering differs between macOS and Linux CI; visual tests need platform-specific baselines.
• CI machines are slower; timeouts tuned on a fast laptop fail under load. Tune timeouts on CI timings.

Provenance

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

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

Thread query: cypress run exits with code 1 but tests pass locally

TL;DR: CI-only failures come from environment differences, not from the tests being wrong. Diff the environments systematically: base URL, test data, parallelism, viewport, and browser version, then reproduce the CI conditions locally with the same container image.

Not specified by the original author.

TL;DR

Passing locally and failing in CI after retries usually means the test depends on state or timing that differs between the two. Run the spec alone and in suite order, then hunt for shared state. Retries mask flakiness; they do not fix it.

Error

Running: specs/checkout.cy.js
  checkout flow
    1) completes a purchase
    2) completes a purchase
    3) completes a purchase

  0 passing
  3 failing

The test failed after 2 retries and will not be retried again.

Steps

1. Run only the failing spec locally with the same retry settings as CI. Expected: this tells you whether the spec alone is flaky or only fails in suite order.
2. Run the full suite locally in the same order CI uses. Expected: if it fails here too, the cause is order dependence, not the CI machine.
3. Look for state shared between tests: database rows, localStorage, files on disk, or a logged-in session leaking across specs. Expected: you can name the shared state.
4. Seed the data each test needs inside a beforeEach hook instead of relying on a previous spec:

beforeEach(function() {
  cy.task('db:seed')
  cy.visit('/checkout')
})

Expected: every test starts from the same known state.

5. Confirm testIsolation is true (the Cypress 12 default) so page state resets between tests, and move any cross-test setup into cy.session(). Expected: no test depends on another test's leftovers.
6. Re-run in CI. Expected: green on the first attempt, not just after retries.

When to use

• A spec passes locally but burns through retries in CI
• The failure moves between tests from run to run
• The suite recently grew past a handful of specs

When not to use

• The test also fails locally (debug it locally first; CI adds nothing)
• The test caught a real bug (fix the app, not the test)
• You only want to change retry counts (see the retries config docs instead)

Tool compatibility

• Cypress 12 through 14, testIsolation and cy.session()
• retries config in cypress.config.js or per-spec
• Any CI provider; the pattern is provider-independent

Variant phrasings

Test retries exhausted in CI pipeline

Same debugging path. Start by reproducing the order locally before touching timeouts.

Flaky test passes on retry locally but never in CI

Local retries can hide a timing assumption that CI always violates. Remove the retry crutch and fix the wait.

Why it happens

Local runs are often a single warm spec with leftover state that happens to help. CI runs the whole suite cold, in order, on a slower box. Tests that read state written by an earlier test, or that assume fast responses, pass by luck locally and fail honestly in CI.

Edge cases

• Fails in CI even run alone: the difference is the environment, not order. Check baseUrl, seed data, and third-party services in CI.
• Passes in CI sometimes: true timing flake. Replace fixed waits with request or DOM waits.
• Only fails on the first CI run of the day: stale or missing seed data. Make seeding part of the job, not a manual step.

Provenance

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

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

Thread query: cypress test retries exhausted but passes locally

TL;DR: Passing locally and failing in CI after retries usually means the test depends on state or timing that differs between the two. Run the spec alone and in suite order, then hunt for shared state. Retries mask flakiness; they do not fix it.