Comments (10)
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
from cypress-docker-images.
from cypress-docker-images.
I'm thinking we would actually cache the last N number of releases.
from cypress-docker-images.
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?
from cypress-docker-images.
@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
from cypress-docker-images.
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.
from cypress-docker-images.
@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
from cypress-docker-images.
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.
from cypress-docker-images.
@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.
from cypress-docker-images.
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.
from cypress-docker-images.
Related Issues (20)
- Feature Branch Request HOT 4
- Security scan of `cypress/included:latest` have significant vulnerability findings HOT 5
- Critical vulnerabilities reported for cypress/factory HOT 6
- Non-fatal caching error with cypress/included in GitHub Actions with non-root user
- Run Cypress interactive GUI on host, but run tests in Docker container HOT 5
- Outdated Cypress Docker Hub Overviews HOT 3
- Suppress publication of cypress/browsers arm64 images with no browsers
- arm64 images contain no browsers HOT 1
- Outdated instructions "Updating images to add linux/arm64"
- Request to update cypress/factory to Debian 12.6
- WARN: FromAsCasing when building Docker image on Linux HOT 2
- docker-image-not-found not compatible with oci mediatype HOT 1
- Replace docker-image-not-found in CircleCI publish workflow HOT 1
- Outdated examples/included-as-non-root-mapped using legacy Cypress HOT 1
- Migrate CircleCI to supported Node.js version HOT 1
- Bump to Node.js 20.15.1 security release
- Update CircleCi to next newer machine image ubuntu-2204:2024.01.1 HOT 2
- CVE-2024-32002 HOT 3
- Transient CI HTTP 502 Bad Gateway errors
- Gitlab pipeline fails with Cypress binary not installed HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cypress-docker-images.