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.
Cypress would split up the installation process into three parts:
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.
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: https://github.com/cypress-io/cypress/issues/4043
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: https://github.com/cypress-io/cypress/issues/3228
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?
@flotwig do you know if dev is in progress for this?
@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.
Bringing this up from an issue with running in Heroku CI. https://github.com/cypress-io/cypress-example-kitchensink/issues/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
)
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.
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
+1 we're also blocked and unable to use cypress for this reason.
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.
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?
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.
+1 on this issue. We love Cypress so far but this makes using it in the Heroku ecosystem much less pleasant.
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.
Any update? :1234:
Most helpful comment
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.