chromedriver
chromedriver copied to clipboard
Tagging different versions
Could you please tag the version of your docker hub images?
Two weeks ago you made a change in the chromedriver image and my tests stoped passing. Those updates changed the way browser session works. The session is asociated to a domain and not shared with others although running in the same tab browser.
If you don't mind tag your images, it's really disappointing this situation
+1 for tags please
At the moment it is very unlikely that I will add tagged versions of the Chromedriver Docker image.
The reason for this is that it would be very difficult to properly express what a version stands for. There are multiple changing parts in the Chromedriver image:
- The Chrome version
- The Chromedriver version
- The Docker image configuration
I will try to keep changes to the Docker image configuration to a minimum, but also won't guarantee so.
My recommendation for anyone using the Chromedriver image for critical infrastructure is to create a fork of the repo and your own Docker automated build.
@blueimp do you have an example of or hint to what that might look like?
It seems like specifying the google chrome and chromedriver version isn't sufficient since they don't seem to play well with each other (at least for me I am getting unknown error: DevToolsActivePort file doesn't exist errors which may (?) be due to a version mismatch despite being in the same chrome major version).
Yes, you will need to use matching Chrome and Chromedriver versions. Which Chromedriver version supports which Chrome version is listed on the Chromedriver Downloads page.
If you have a need to tag individual Chrome versions, you likely want to hardcode those versions (plus the related Chromedriver versions) into your Dockerfile.
The latest release breaks our CI because of Chromedriver issue 3857.
Apparently, the latest commit to this repo is supposed to deal with that by adding a proxy. However, we're getting
Host header or origin header is specified and is not whitelisted or localhost.
Right now I'm trying to scramble to fix CI. The easiest way would be to lock to the previous image until I've this sorted out, but I can't. (At least not with my humble docker skills.)
Could you use date and/or serial number for tags?
The docker image is a dev dependency for many projects, so it would be really nice if users could lock a particular version and upgrade whenever they have time to test.
Hi @drjayvee, I'm sorry to hear that your CI build broke. Unfortunately the issue you referenced was a breaking change in Chrome that I had no control over. The reverse proxy solution I added does work in the setup I've tested (https://github.com/blueimp/wdio), as long as your webdriver client does not send an Origin header for the Webdriver API requests. Host checks are mitigated with the reverse proxy and I'm not aware of a webdriver client using an Origin header unless they would be running in a web context.
Regarding adding tags, my opinion on this has not changed since my previous statement above. In addition to what I wrote there I also want to avoid the responsibility of maintaining a list of tags, especially since older tags would likely contain security issues.
I still strongly recommend you to fork and create your own tags that you can rely on.
I think one tag per Chrome version (which automatically means the matching Chromedriver version as well) would be sufficient.
This is the third time that Chrome/Chromedriver broke something since I use this image and each time pinning a certain Chrome version until the next one is released with a fix would have been the easiest solution.
It'd be probably enough to keep the last 5 or so around.
I've added guidance on the README with a strong recommendation to using your own tagged Docker images: https://github.com/blueimp/chromedriver#tags
If there is demand for a hosted version of tagged chromedriver images, maybe someone in this thread is willing to set this up and maintain it?
Thanks for taking the time to explain and take this seriously. I think your documented recommendation is a sufficient solution.