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 browserless.
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 browserless.
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 browserless.
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 browserless.
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 browserless.
Related Issues (20)
- V2 cannot use proxy HOT 5
- SyntaxError: Invalid URL: "=wss://" inside railway service HOT 1
- Browserless Timeout 60000ms exceeded after running for 2 days HOT 2
- Unable to get free trial
- [🔴] Unable to use browserless using docker! HOT 1
- V2 error: No matching WebSocket route handler for "http://0.0.0.0:3000/?launch=%7B%7D" HOT 1
- Unable to use proxy with /function api in v2 HOT 1
- Can't increase timeout: TimeoutError: Navigation timeout of 30000 ms exceeded HOT 1
- Please update version of serialize-javascript in use by image dependencies HOT 3
- Chrome v2.8.0 No matching WebSocket route handler HOT 2
- Log data accumulation causing excessive use of computational resources (hard disk). HOT 1
- Can I set up a header browser after connecting? HOT 3
- docker container crashes when using custom user HOT 1
- Browserless Chromium through Docker 2.8.0 tag - Live debugger - ignoreHTTPSErrors invalid parameter HOT 2
- Can't update from 2.20-5 HOT 2
- Error: "browserless:server /: Forbidden. Behavior of "http" set, writing response and closing." running browserless in docker HOT 2
- Dockerized - server returning 404s for good endpoints (/metrics and /active) HOT 1
- I'm using Puppeteer to connect to Browserless for screen recording, but I'm unable to capture the audio stream HOT 2
- Selenium wire support or network interception ? HOT 1
- Enable debugger in docker image HOT 3
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 browserless.