skip to content

In Cypress CI, should you pin Chrome for Testing or use the installed Chrome?

level: principalimportance: nice to knowfreq 27%

answer

  1. One build never updates itself
  2. Reproducibility and early warning pull apart
  3. Two jobs can answer two different questions
  4. Cypress supports only recent major versions
  5. Write the choice into the config, not the job

basics

~20 s

Pin Chrome for Testing where a red run must mean a real regression, and keep a separate evergreen job so browser changes still reach you. A pin buys reproducibility, not immunity from the next Chrome release, and it needs a bump schedule.

solid answer

~50 s

There is no single answer; the two options answer different questions. **Chrome for Testing** is a Chrome flavour Google builds for automation: it never auto-updates, a matching versioned build exists for every Chrome version and major OS, it is generally outside the enterprise policies applied to branded Chrome, and it can still load extensions through Cypress's `before:browser:launch` event, which branded Chrome 137 and above cannot. Pin it, launch with `cypress run --browser chrome-for-testing`, and a failure means your code changed. **Evergreen Chrome** answers a different question: does the app still work in the browser users have today. The usual resolution is both - pin the blocking pre-merge job, and run a scheduled job on the evergreen browser so a Chrome change reaches you before a customer does. Whatever you pin needs a bump schedule: Cypress supports only the latest three majors.

go deeper

for a junior

Know that Chrome updates itself and that Cypress can also launch Chrome for Testing, a build that does not. You are not expected to own the choice between them.

for a middle

Explain what changes when a run targets a pinned browser rather than an evergreen one, and how a browser is selected so both are reachable from the same project.

for a senior

Show how you would arrange jobs so a red pre-merge run is attributable to the change under review while browser-side change still reaches the team quickly.

for a principal

Own the standard: which build the blocking suite runs, who bumps it and how often, and what the organisation is entitled to claim from a run on a pinned browser.

This is a genuine trade, not a best practice with one right side, and it is worth having a position on because it decides what a red Cypress run *means* in your organisation. ## What Chrome for Testing changes Chrome for Testing is a Chrome flavour Google publishes specifically for automation. Compared with a branded Chrome install, and from Cypress's point of view: - **It does not auto-update.** Branded Chrome is evergreen and updates itself silently, so a suite that passed yesterday can fail today with no commit to blame. - **Every version has a matching, published build** for each major OS, so the same browser can be installed locally and in CI. - **It is generally outside the enterprise policy** that organisations apply to branded Chrome, which removes a common class of launch problem on managed machines. - **It can still load extensions** through Cypress's `before:browser:launch` node event. Branded Chrome 137 and above no longer can; Chrome for Testing and Chromium still do. - **It is selected like any other browser**: `cypress run --browser chrome-for-testing`, and it reports `family: 'chromium'` to `Cypress.browser`. ## What a pin actually costs you A pinned browser does not make your product's browser risk go away; it moves it out of the pre-merge signal: - You lose the **early warning**. When an evergreen Chrome release changes behaviour your users will meet, a pinned suite stays green and you find out from a support ticket. - You acquire an **upgrade job**. Cypress officially supports only the latest three major versions of Chrome, Firefox and Edge, so a pin left alone drifts out of the supported window within months, and a Cypress bug in that browser is no longer something you can report. - You acquire an **image to maintain** - the pinned build has to be installed somewhere, and that somewhere is now part of your build. ## A split that usually works 1. **Pin the blocking job.** The pre-merge run that gates a merge uses a fixed Chrome for Testing build, so a red result means the change under review broke something. 2. **Run an evergreen job on a schedule.** A nightly or per-release run against stable, and optionally beta or canary, catches browser-side change while there is still time to react. It reports, it does not block. 3. **Bump the pin deliberately.** Treat it as a dependency update with its own commit and its own green run, so a browser upgrade and a code change never fail together. The point of the split is that the two jobs answer different questions, and a single job cannot answer both honestly: | | Pinned Chrome for Testing | Evergreen installed Chrome | | --- | --- | --- | | Question it answers | Did our change break it? | Did the browser break it? | | Failure attribution | The commit under review | Could be either side | | Browser drift between runs | None | Silent, whenever Chrome updates | | Maintenance you owe | A scheduled version bump | None, until a run goes red | | Where it belongs | The blocking pre-merge run | A scheduled, reporting-only run | ## Making the choice explicit in the project - Put the browser in `defaultBrowser` rather than in each pipeline file, so local runs and CI agree by default. - Filter the `browsers` array returned from `setupNodeEvents` to remove browsers you do not intend to support, so `cypress open` offers the same short list to everyone. Returning an empty array or `null` restores the full default list, so filter rather than clear. - Record the pinned version somewhere a human reads - the image tag or a lockfile-like note - not only inside a base image several layers down. ## When branded Chrome is the right answer Pinning is not free, and for some teams it is not worth it: - **A small suite on a fast-moving product** may prefer evergreen Chrome everywhere and simply absorb the occasional browser-caused failure, because the diagnosis cost is low. - **A team without image ownership**, running on a CI provider's managed browsers, may find pinning theoretical rather than achievable. - **A suite that already runs several engines** gets some of the same early warning from the other browsers, which reduces the value of an extra evergreen job. - **A team that cannot act on the warning quickly** gains little from receiving it earlier; a nightly job nobody reads is worse than no job, because it manufactures the feeling of coverage. The judgement to articulate in an interview is this: pinning is about making failures attributable, not about correctness. If you pin, own the bump. If you do not pin, own the fact that some red runs will be the browser's doing, and make sure the team can tell those apart quickly rather than re-running until green.

  • How do you stop a Cypress project offering browsers your team does not support?
    Filter the `browsers` array in `setupNodeEvents` and return the shortened list - for example keeping only entries whose `family` is `'chromium'` and whose `name` is not `'electron'`. That list is what `cypress open` offers. Returning an empty array or `null` restores the full default list, so filter it, never clear it.
  • What does Cypress's three-major support window mean for a pinned browser?
    Cypress officially supports the latest three major versions of Chrome, Firefox and Edge, so a pin is a lease rather than a purchase. A build pinned and forgotten falls out of that window within months, and at that point a Cypress problem in that browser is not something you can usefully report. Budget the bump the way you budget a dependency upgrade.

saying these in an interview costs you the question

  • Pins a browser build and never schedules a bump
  • Thinks pinning removes the need to test current Chrome
  • Treats Chrome for Testing as a different rendering engine
  • Assumes an evergreen browser still gives reproducible runs