Pre-cache cypress binaries

[cypress-io]

Pre-cache cypress binaries

[bahmutov]

I think this is not worth doing. Because you still need to install other NPM dependencies, and you still would like to cache them, thus caching Cypress binary (as described here https://docs.cypress.io/guides/guides/continuous-integration.html#Caching-the-Cypress-Binary). CIs do a really good job caching folders, for example https://circleci.com/gh/cypress-io/cypress-example-recipes/6999 restores cached modules in 11 seconds and installs NPM modules in 12 seconds

So I

• don't see any performance gain from including Cypress binary in the docker image
• might cause version clash
• a lot of extra things to do and support

[bahmutov]

Gotcha, might be a pain, but why not

…

Sent from my iPhone

On Apr 14, 2018, at 11:32, Ben Kucera ***@***.***> wrote: I imagine we would maintain multiple images, one for each Cypress release, so only one Cypress binary per image. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[brian-mann]

I'm thinking we would actually cache the last N number of releases.

[ianwalter]

So now that the above linked feature has been added to Cypress maybe a quick win would be to just add npm install -g cypress to the Dockerfiles so that the latest Cypress binary is baked in to the images?

[kuceb]

@ianwalter that would have devastating effects since users have a package.json with a specific Cypress module version that is not compatible with the latest binary version

[ianwalter]

How so? It would simply cache the latest binary, and if the user is using the latest version, it will use that binary, if they are not, Cypress will download the other version since it's not cached right? If you cache a bunch of versions then you have to worry about the image size being a bit bloated and updating all of the Dockerfiles every time there is a new release. So I was just proposing a quick and easy solution that would benefit some users and not really affect other users because it would continue to function in the same way as it does now. Admittedly my team uses the latest version of Cypress though.

[kuceb]

@ianwalter as soon as a project falls behind on a Cypress version, the build process would have to go out and download the large binary on every build, in addition to the next version of the binary unnecessarily. Without a project even knowing, their builds would become a lot slower, if not break if they are caching node_modules and not executing the postInstall script before cypress run

[ianwalter]

No, I think you're misunderstanding what I'm saying, if users aren't using the latest, they don't have to download 2 binaries as you are suggesting, they would only have to download their version (same way it works now) or 0 binaries if they are using the latest since the feature above should detect its presence. The latest binary would be built into the image so once you pull that image you don't have to download it again (and it's faster since you don't have to unzip, compile, etc). So this shouldn't slow down builds at all or break anything.

[kuceb]

@ianwalter if users are relying on the docker image to include the binary, they require no caching of the binary at all on their end. Cool.
But if they fall behind the cypress version, their builds are not configured to cache this binary- so this download will happen every time.

[ianwalter]

You know what, it's not important :) Either long term solution, creating an image tag per version or installing the last N versions into the image, works for me. Thanks.