selenium-powershell icon indicating copy to clipboard operation
selenium-powershell copied to clipboard

Chrome Driver Version Management

Open eelkram opened this issue 5 years ago • 7 comments

Hi @adamdriscoll,

I was wondering how you are planning on managing Chrome Driver versions and keeping it in sync with the version of Chrome running on the system? I want to be able to handle Chrome updates for my use case and would like to continue using this module.

It seems like we need to add functionality to automatically download the matching version of the driver to keep it in sync with the version of Chrome that is running on the users system. Assuming you agree, I'd be happy to put together an initial implementation and submit as a PR.

Thoughts?

Thanks, Mark

eelkram avatar Oct 31 '19 05:10 eelkram

I think thats a great idea because we have to push to the repo every time a new version comes out. It'd be awesome if you threw a PR in!

adamdriscoll avatar Nov 08 '19 15:11 adamdriscoll

+1 The only problem with it are that the drivers are a moving target. From my experience (releasing a few driver updates so far) is that the latest drivers are not always the best or the most stable so I test them pretty thoroughly. Another thing to take into account is security. If you look at the updates I've done i always make sure the executable are scanned on virustotal by many anti-viruses you never want to infect someone else's computer because your module downloaded the wrong file. I think the approach for this should be to automate the process that grabs the files extracts them and scans them but still do the push to github/review the virus scan etc manually.

-DM

the-mentor avatar Nov 18 '19 19:11 the-mentor

All driver versions are also available via chocolatey:

https://chocolatey.org/packages?q=selenium

majkinetor avatar Dec 27 '19 21:12 majkinetor

Currently I'm keeping pace with this solely with those Chocolatey packages.

Would be awesome to have something like this automatically handled by the module. Also, those Chocolatey packages install the webdrivers to C:/tools so it'd make some sense if this module just looked in that location for appropriate files as well, rather than necessarily storing them in its own module folder.

vexx32 avatar Mar 27 '20 13:03 vexx32

Sorry for the slow response on this..

Based on the feedback, I'm not sure if a PR would be accepted or how you would be looking at wanting it implemented. For anyone else looking at this, I've implemented driver version management for Chrome in my project here: https://github.com/beyondcomputing-org/AWS.SAML/blob/master/AWS.SAML.ChromeDriver.psm1 and leverage the new WebDriverDirectory parameter.

@adamdriscoll - Let me know if you would like me to port this over as a PR for the Selenium module. If so, we need to discuss where you want to store the driver files for this project.

eelkram avatar Apr 04 '20 23:04 eelkram

I will be looking at this in the next few weeks.

I like the sum of ideas proposed here.

The key points to me:

  • Module still ship with pinned version
  • Driver update is not automatic by default.
  • Exposed cmdlet allow updating the drivers from within the module (but do not overwrite the default, of course)
  • User leverage WebDriverDirectory to use the latest drivers instead of the default.

On keeping up with the more recent driver

  • CI pipeline grab the new drivers automatically, run combined tests but requires manual review.

This would result in 2 things.

  • User can update module by calling the cmdlet independently of Module provided driver. By doing so, security becomes user responsibility (I think a message should be displayed to specify the location from where the driver was obtained and that user should use that driver only if he trust it) .

  • Modules provided versions can also be kept more up-to-date and embedded in the module since CI would automate the worst part of it.

I am actively working on the module (scaffolding, help, V4.0) but I will definitely be looking more in depth in a few weeks.

As for the path, I was thinking these could be stored into either ProgramData or Appdata depending on the scope the module was installed.

Something such as

#$env:APPDATA 
$DriversPath = Join-Path -Path $env:ProgramData -ChildPath 'Powershell\selenium-powershell\drivers'

(I need to validate the equivalence for Linux / MacOs)

itfranck avatar Aug 08 '20 08:08 itfranck

You might be able to use the excellent WebDriverManager.NET for this: https://github.com/rosolko/WebDriverManager.Net

Sebazzz avatar Mar 30 '22 11:03 Sebazzz