Separate Electron, Cypress app code, and ffmpeg into individual downloads

[flotwig]

Current Behavior

Cypress is downloaded as one large .zip (140MB zipped, 387MB unzipped on Linux) file that contains Electron, Cypress's app code, and ffmpeg.

Updates are sent out as new versions of the .zip, containing all three of those elements.

Desired Behavior

Cypress would split up the installation process into three parts:

1. Downloading Electron launcher
2. Downloading ffmpeg
3. Downloading Cypress code

Electron and ffmpeg are less-frequently-updated than Cypress itself, so we could probably help users cut down on their install sizes quite a bit after a few upgrades. Some users have noted that the installs tend to stack up after a while: #912

This would require separating Cypress from the Electron binary so that we could release them independently. Also, users would still need to be able to download an all-in-one .zip from the website for "global" mode.

[eugene-matvejev]

I do agree, we need somehow separate these things, so people might not install unneeded stuff, if they got lets say chrome installed I discussed it here: #4043

[jennifer-shehane]

I want to ask if the intent of this PR would allow each individual installation support different versions of the other installation? Or would they all have some 'min version' requirements for the other installation? Also this would not satisfy this request basically: #3228

[MeStrak]

I think the main point is separate the binaries so that they can be installed and run independently. Publishing a range of versions supported by the package would be good.

Unfortunately #6012 was closed but this would be ths solution. If the binaries were separated, Chrome and Cypress could be installed withought the need for Electron, therefore no need for Xvfb.

@jennifer-shehane I see that this has been in Stage: Ready for work since April 2019. Is work likely to start soon on this?

[MeStrak]

@flotwig do you know if dev is in progress for this?

[flotwig]

@MeStrak no, not currently. fyi, you can check the "stage" labels in issues to get an idea of what the current status of an issue is.

[jennifer-shehane]

Bringing this up from an issue with running in Heroku CI. cypress-io/cypress-example-kitchensink#324

This feature would be nice when users want to run Chrome headless only to not require some of the deps that Electron itself requires (like xvfb)

[ext]

This feature would be nice when users want to run Chrome headless only to not require some of the deps that Electron itself requires (like xvfb)

That is our use-case as well and this is currently a blocking issue preventing us from using Cypress in our CI environment. It's a shame since we use other tools which runs fine with Chrome headless but we are unable to install xvfb for security reasons.

[erwanriou]

Bringing this up from an issue with running in Heroku CI. cypress-io/cypress-example-kitchensink#324

This feature would be nice when users want to run Chrome headless only to not require some of the deps that Electron itself requires (like xvfb)

+1 here we are also block because of this issue

[shanebo]

+1 we're also blocked and unable to use cypress for this reason.

[benhutton]

Is there any sense of when this could happen? We have put considerable work into getting Cypress going, and are now jammed up because Cypress won't run on modern heroku. We need to know if we should sit tight and wait or if we need to change tooling somewhere, somehow.

[MeStrak]

Thanks @flotwig I didn't know where I could find the different possible stages. I guess the next one is investigating, before backlog?

@jennifer-shehane as @benhutton asked, is there any way for us to know the internal priority of this for Cypress?

[Dangeranger]

As some food for thought, we moved away from Heroku-CI and onto using Github actions for End-to-End testing because of this issue.

[pkiv]

+1 on this issue. We love Cypress so far but this makes using it in the Heroku ecosystem much less pleasant.

[lnm8910]

Hey guys, any update on when are we going to be able to run cypress on Linux without installing xvfb? Sometimes we don't have control over the environment.

[slavoroi]

Any update? 🔢

[AncientSwordRage]

Still looking for an update, any progress?

[jennifer-shehane]

What are the primary situations on where this is required?

I see Heroku mentioned specifically, are there other environments/setups where this is a blocker to running Cypress?

[ext]

@jennifer-shehane My biggest issue is the fact that headless still requires Xvfb to run and this issue seems to be a blocker (see the many referenced bugs). Additionally, enterprise firewalls might block downloads such as these (my employer does) which really complicates npm install cypress.

[s5no5t]

@jennifer-shehane my use case would be switching to Chrome in CI, and not having Cypress download Electron as well in order to reduce CI runtime.

[Michenux]

Without xvfb requirement, we could run cypress in lambda functions to scale test workload.

[sovanyio]

This is a blocker to running cypress on my enterprises' version of jenkins (and web operations is not interested in upgrading or maintaining more packages).

[MeStrak]

@jennifer-shehane for me it's the same as @Michenux - running in AWS Lambda.

[smccarthy-godaddy]

@jennifer-shehane Same as for me.

[mvanini]

any chance to close this?

[loveforty]

Can we get our own devs working on this? I think it would be faster :dead:

[mfittko]

we would really appreciate this, it takes up like more than 10 seconds for every cypress runner on our CI just to restore the huge cypress binary from cache (due to it having electron and ffmpeg included, which we don't really need). That makes adding more parallel nodes (or the setup part that is needed in a docker container before running the first cypress test) unnecessarily expensive. Come on, let's get this done please!

[evanjmg]

Why is this in the icebox? This stops all enterprise adoption altogether - thus you will have less contributors to your project.