angular / webdriver-manager

A binary manager for E2E testing
MIT License
225 stars 116 forks source link

Cache results of `webdriver-manager update --android` #150

Open sjelin opened 8 years ago

sjelin commented 8 years ago

Right now it does the whole thing from the start every time -- takes forever.

sjelin commented 8 years ago

Maybe a feature like --force for all update commands. Unless --force is used, don't try to install something which appears to already be there.

darrinholst commented 7 years ago

Is there no caching for any drivers?

I run an update for something that's up to date...

1__tmux_-2_attach____tmux_-2_new__tmux__and_cache_results_of_ webdriver-manager_update_--android _ _issue__150_ _angular_webdriver-manager

...and it still downloads 20mb

charles_4_0_2_-_session_1__

I don't remember it doing this "before"

sjelin commented 7 years ago

I believe there is no caching

darrinholst commented 7 years ago

10.2.8 changed the HEAD request to a GET to get the content length which is why I remember it not taking so long - https://github.com/angular/webdriver-manager/compare/10.2.7...10.2.8#diff-723753646e6ae3d61a045f858de87bd3L91

There are a lot of changes in master to downloader so not sure if it has the same behavior...downgrading to 10.2.7 fixes my immediate problem.

sjelin commented 7 years ago

A chat between @cnishina and I:

Sammy Jelin (sjelin@google.com):
any thoughts on this: https://github.com/angular/webdriver-manager/issues/150#issuecomment-263942098

Craig Nishina (cnishina@google.com)
yes, the new way is to do a single GET request... if the content-length is the same as the file, we abort the request. 

Sammy Jelin (sjelin@google.com):
I see, but then it's slower if the length is the same
because we've sent a GET request

Craig Nishina (cnishina@google.com)
Yes. It could be slightly slower. Before it was doing a HEAD request. I changed it to GET because gecko driver
cnishina commented 7 years ago

:point_up: This is currently in master and we will have a release soon.

boneskull commented 7 years ago

This may be related (and is happening against current master):

chromedriver's default version is 2.27. But the latest version is 2.28. If you don't specify 2.28 via --versions.chrome=2.28 on the command line, webdriver-manager will download the file every time.

I did a bit of digging around:

// require('./built/lib/files/file_manager.js').FileManager.downloadedBinaries('./selenium').chrome
DownloadedBinary {
  ostype: 'Darwin',
  osarch: 'x64',
  cdn: undefined,
  versions: [ '2.28' ],
  binary: 
   ChromeDriver {
     ostype: 'Darwin',
     osarch: 'x64',
     cdn: 'https://chromedriver.storage.googleapis.com/',
     configSource: 
      ChromeXml {
        ostype: 'Darwin',
        osarch: 'x64',
        out_dir: '/Volumes/alien/forked/webdriver-manager/selenium',
        name: 'chrome',
        xmlUrl: 'https://chromedriver.storage.googleapis.com/' },
     name: 'chromedriver',
     versionDefault: '2.27',
     versionCustom: '2.27' },
  name: 'chromedriver',
  versionCustom: '2.27' }

FileManager wants to do size comparisons against the DownloadedBinary#versions prop and ChromeDriver#versionCustom prop. Since it can never find a match--we've only downloaded v2.28--it just goes and downloads v2.28 again.

The workaround is to be explicit about the version you want:

$ webdriver-manager update --versions.chrome=2.28 --standalone=false --gecko=false
webdriver-manager: using project version 12.0.4
[22:19:42] I/update - chromedriver: file exists /Volumes/alien/forked/webdriver-manager/selenium/chromedriver_2.28.zip
[22:19:42] I/update - chromedriver: unzipping chromedriver_2.28.zip
[22:19:42] I/update - chromedriver: setting permissions to 0755 for /Volumes/alien/forked/webdriver-manager/selenium/chromedriver_2.28
[22:19:42] I/update - chromedriver: chromedriver_2.28 up to date

It still unzips again, but at least doesn't curl.