[Vinnl]

I've been running WebdriverIO in Docker for a while now, as follows:

On my CI server (using GitLab CI), I run a Node Docker image, and connect the Selenium Firefox [1] or Selenium Chrome [2] Docker image to it. I then install WebdriverIO, and tell it to find Selenium on that container's hostname.

This works, but is a little bit brittle, and I've had to pin the Selenium image versions because something broke at a certain point and it didn't seem worth it to fix it yet.

Which is to say: I'd very much be in the market for using the containerised versions of Chrome and Firefox, if there were instructions for doing so in CI - the primary use case for browser automation, in my opinion.

I realise that this might not be your intended usage, but figured I'd provide this feedback just in case it is.

[1] https://hub.docker.com/r/selenium/standalone-firefox/

[2] https://hub.docker.com/r/selenium/standalone-chrome/

[blueimp]

Hey Vinni,

you can definitely use this project and the containerized versions of Chrome/Firefox on CI - in fact that's its primary use case.

The way this project is setup is to use the chromedriver/geckodriver servers directly, without using the selenium Java server.

My recommendation for anyone using this in a production CI system is to fork the wdio, chromedriver, geckodriver and underlying basedriver repos and set up your own Docker automated build for them.

For a given GitLab repository, you would add this project as a folder and modify the provided docker-compose.yml to replace the example app with the application files from your repository.

Please let me know if I can help you with additional instructions.

[Vinnl]

Ah, but for me the main appeal would be to point it to an image, and then not having to maintain it myself - which is what I'd be doing with forking, and which is basically what I'm already doing, but with more work.

So for example, in my GitLab CI config, I've simply added the following lines to my job configuration:

  services:
    - name: selenium/standalone-firefox:3.13
      alias: selenium

I can then simply tell my wdio config that Selenium is running at `selenium` (i.e. `wdio --host=selenium`), and it will work.

However, the setup is somewhat brittle, doesn't work with the latest versions of Selenium (and I can't be arsed to fix it), and I think it still starts an X server. If, instead, I could simply point it to an image that runs headless Firefox, is maintained, and intended for use with wdio, then that would be an excellent time saver.

When I have to fork, however, the hurdle to start using this is a lot higher, and the savings of not using the Selenium Java server is not really worth the additional effort.

[blueimp]

Well you can use the provided images without forking and they both support running Chrome/Firefox headless without X.

But since I'm building this in my personal time there's no professional support nor a guarantee that it won't break, so I would still recommend to fork it.