Connect to remote browser instead of locally launching chromium

[drnic]

Pass in options.browser_ws_endpoint to connect to a remote browser, such as https://browserless.io

For example:

options = {"browser_ws_endpoint": "wss://chrome.browserless.io/?token=#{ENV["BROWSERLESS_API_TOKEN"])}"}
grover = Grover.new("https://mysite.com/path/to/thing", options)
File.open("grover.png", "wb") { |f| f << grover.to_png }

[drnic]

@abrom you ok with the codeclimate warning?

[abrom]

hi @drnic

Thank you for the PR. I see that there appears to be a whole heap of unrelated refactoring done. Can you please limit your PR to just the parts related to the change at hand.

I also see that there are no tests to go with this change? To ensure that we don't end up with any regressions in future changes it would be highly beneficial to have some tests included to go with this. I can't say I've spent a lot of time looking into this, but I can see that browserless do support a "demo" system (by simply not providing an API key). See https://docs.browserless.io/docs/faq.html#how-can-i-try-out-the-service Although to ensure we don't end up rate limiting ourselves it's probably a good idea to limit which intersections of the build matrix would actually run the test! (at last count there are 40 jobs run per build)

Note it looks like the Travis CI integration has broken. I will look to fix that

[drnic]

Hmm, my editor has generously reformatted your javascript. I'll recreate the commit from scratch and disable my linter/formatter.

Re adding tests -- firstly, sorry I forgot to investigate the test suite. I was just happy that I got it working at all :)

Secondly, it would be sufficient to run a minimum number of tests that interact with browserless or similar service just to continuously confirm that no one has broken is feature/code path?

[abrom]

No worries.

So I was having a think about how to best test that it works (and be sure that it is actually using the specified remote endpoint

• and not just rendering it locally). It looks like Browserless supports passing in various launch options, including window size. See https://docs.browserless.io/docs/chrome-flags.html#starting-chrome-with-a-width-and-height (just don't use 800x600 as that's the default!)

With that you should be able to simply test that a screenshot has the appropriate matching width an height. I would use a screenshot rather than a PDF as the PDF would obviously have a fixed (or specified) size. You could still use a PDF, but it'd probably require some JS to get the window size then display it in the PDF followed by testing the PDF text content for the expected width/height copy. I would suggest putting the new test in the processor_spec.rb file in the "with converting to an image" context.

To limit the number of times that specific spec will run (and potentially cause issues with overusing the Browserless "free" sans API token service), suggest wrap the context for the new spec in the puppeteer_version_on_or_after? method. Suggest use '10.0' for the version as this will result in only 4 calls to Browserless (one per Ruby version). Although to ensure it will run if outside the CI env you could also add ENV['CONTINUOUS_INTEGRATION'] != 'true' or similar.

i.e.

if puppeteer_version_on_or_after?('10.0') || ENV['CONTINUOUS_INTEGRATION'] != 'true'
  context 'when specifying browser WS endpoint'
    ....

[abrom]

Any update on this @drnic ?

[abrom]

FYI @drnic this has been released in v1.1.5 from #178