The autoUpdateDrivers KRE option downloads new drivers in a temp directory which it does not use for running TestSuites

Product Forums Katalon Studio
,
1

We are using Katalon Runtime Engine (KRE).
We are trying to use the –config -webui.autoUpdateDrivers=true option, to avoid issues when browsers have been updated.
We are focused on Chrome (which uses ChromeDriver driver) and Firefox (which uses Gecko driver).
The following takes place on a Windows10 machine.

Before using the autoUpdateDrivers option, we had observed that the drivers are stored in the C:\Katalon_Studio_Engine_Windows_64-8.1.0\configuration\resources\drivers “DRIVERS” sub-directories.

In the console log, when KRE is booting, KRE says:

chromedriver is located at default location: C:\Katalon_Studio_Engine_Windows_64-8.1.0\configuration\resources\drivers\chromedriver_win32\chromedriver.exe. In case your browser is updated to a newer version, please use this command to update chromdriver: --config -webui.autoUpdateDrivers=true

For example:

C:\Katalon_Studio_Engine_Windows_64-8.1.0\configuration\resources>drivers\chromedriver_win32\chromedriver.exe -v
ChromeDriver 92.0.4515.43
===> as the machine now runs Chrome 94, we expect an upgrade.

We use the --config -webui.autoUpdateDrivers=true option.

We have observed that, as a result, KRE creates a new “TEMP” directory and sub-directory.

In the console log, KRE says that it is now working with the new directory.

Chrome driver is located at: C:\Katalon_Studio_Engine_Windows_64-8.1.0\configuration\resources\temp\webdriver\chromedriver.exe

Indeed, the new drivers get downloaded in that “TEMP” sub-directory.

C:\Katalon_Studio_Engine_Windows_64-8.1.0\configuration\resources>dir temp\webdriver
(…)
11,232,768 chromedriver.exe
3,300,792 geckodriver.exe

But KRE, when running the Test Suites, still tries to use the drivers from the “DRIVERS” sub-directories.

Indeed, if we just delete those (old) drivers from the “DRIVERS” sub-directories before running KRE, the Test Suites fail, with KRE logging:

Caused by: java.lang.IllegalStateException: The driver executable does not exist: C:\Katalon_Studio_Engine_Windows_64-8.1.0\configuration\resources\drivers\firefox_win64\geckodriver.exe
Caused by: java.lang.IllegalStateException: The driver executable does not exist: C:\Katalon_Studio_Engine_Windows_64-8.1.0\configuration\resources\drivers\chromedriver_win32\chromedriver.exe

The workaround looks easy: just copy from “TEMP” to “DRIVERS”…

cd C:\Katalon_Studio_Engine_Windows_64-8.1.0\configuration\resources
copy temp\webdriver\geckodriver.exe drivers\firefox_win64
copy temp\webdriver\chromedriver.exe drivers\chromedriver_win32\

But this suggests that:

  • either we are not using the autoUpdateDrivers option effectively,
  • or there is an issue with the KRE product (it forgets to copy from “TEMP” to “DRIVERS”?)

Has anybody observed similar issues? What are we doing wrong?

2

We are also having issues where using autoUpdateDrivers sometimes causes the Chrome and Chrome driver versions to be out of sync. We are using a powershell script in TeamCity to run as a build step before the Katalon execution step to download the latest Chrome driver that matches the installed version of Chrome. Because we pull the Chrome version from the registry and the chrome driver version doesn’t always match the same point release, this can also lead to problems where when go to Google’s FTP and that particular point release of the driver cannot be found. We still have not found a simple solution to this problem, so it would be much easier if autoUpdateDrivers worked! A switch to automatically update to the latest version of a browser would be nice as well, that way we don’t have to go to each of our test automation execution machines and ensure that Chrome itself has updated.

3

@eric.martin1,

I had the same problem and moved –config -webui.autoUpdateDrivers=true to be the last two parameters in my CLI command. Once it was moved to the end then ChromeDriver was updated in the temp\resources folder like @michelg mentioned. AND KS actually used that version. I verified the chrome driver version by opening a command window to both locations and entered “chromedriver -version”. The “expected” chromeDriver location was out of date, and the temp location chromeDriver was current. Since chrome launched without issue, I can only assume that the temp chromeDriver was used.

  1. Why does location in the CLI command matter??
  2. Why doesn’t the log state the chromeDriver version and where it’s location? It look like the path was hard-coded because the logs always state the “expected” location and not the actual location.

At least it is working for me now…