Comments (5)
Hi, I am a little bit concerned about the size of the new image. I can imagine, that I would like to use 2 latest versions of chrome for some e2e testing, to check, that my website works for most of the users. But I dont see many reasons to check performance in multiple chrome versions, or any other use case. I am more afraid of the image size, since we are using your image inside CI, where it is not always cached and it would mean longer execution times, since each chrome is ~282Mb big (according to puppeteer readme). Also I dont see a need to have multiple release-puppeteer-x.x.x images merged in one, since probably most users will use one specific version of puppeteer and not multiple.
Maybe it would be good to write down some real use cases, which would be affected by this change.
Our scenarios:
- Image is running on the server to which we connect from our local computers to execute some tests - This change would not affect this scenario in any way
- Image is downloaded inside our CI, where it is used to execute some tests - This change may cause slow down of our pipelines
So from my perspective, it would be better to keep the things the way they are now, but I can understand, it can be time consuming to maintain more versions of the image. Thanks for your work!
from chrome.
Been thinking some more about this, what if we made puppeteer a “runtime install”. That way I’ll install whatever version you want on start (defaulting to latest), and it’s less maintenance overhead?
from chrome.
If I understand it correctly, it would mean, that by running docker run, you would download the chrome for specified puppeteer version.. It would still cause extended execution time for our pipelines. Maybe we could take an inspiration from selenium grid.
You could have one docker image with server/hub (practically just this repository without any chrome downloaded) and then multiple docker images with different chrome versions. User would connect to the server and request a chrome instance with specified version, if a docker image with specified chrome version exists, it would create the chrome instance and the server would work as some sort of a bridge between the chrome node and user.
In this case, you would maintain only one docker image with the server. Other images with chrome installed should not need any maintenance. Users would just download the versions they need.
from chrome.
Since Puppeteer is so sensitive to Chrome versions, it seems very important to be able to define a version when launching browserless. Several use cases involve messing around with Chrome internals (e.g. saving userDataDir elsewhere), and across different versions it'd just break.
Being bundling different versions or selecting at runtime, this is generally a very good idea.
from chrome.
Going to close this out as we’ll continue to do version-specific releases. I think I’ll give more thought on how to do this in a sane manner.
from chrome.
Related Issues (20)
- Guidance: Are "chrome-stable" docker image tags EOL? HOT 3
- The PDF is blank when downloaded
- Browser keeps getting closed after exactly 300 seconds since starting the job HOT 5
- When using chrome instead of chromium : Execution context was destroyed, most likely because of a navigation. HOT 4
- goto() function does not load any website HOT 1
- blockAds=true on Firefox HOT 3
- License Clarification HOT 1
- browserless/chrome (v1) on Docker Hub is no longer built for ARM64 HOT 1
- ghcr.io/browserless/chrome:latest (v2) is no longer built for ARM64 HOT 1
- TimeoutError from puppeteer without an option to increase it? HOT 2
- Difference in response between v1 and v2 HOT 5
- V2 Chrome puppeteer.connect not passing options through properly with curly brace HOT 2
- Sharing cache between docker containers HOT 1
- Migration from 1.x to 2.x: trackingId not usable?
- Cannot launch browser with multi:2.2 HOT 4
- /scrape API - custom behavior with waitFor and dynamical loading page HOT 1
- "launch.blockAds" is not allowed HOT 4
- 2.2.0: no matching manifest for linux/arm64/v8 in the manifest list entries HOT 4
- args param and DEFAULT_LAUNCH_ARGS are ignored HOT 7
- Implement Prometheus Metrics format HOT 1
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 chrome.