add relay builder

[mikk150]

Thanks for contributing to the Docker-Selenium project! A PR well described will help maintainers to quickly review and merge it

Before submitting your PR, please check our contributing guidelines, applied for this repository. Avoid large PRs, help reviewers by making them as simple and short as possible.

Add node-relay image that generates config for selenium relay

Description

Add node-relay that can be used to use providers and applications that supports WebDriver protocol.

This could be used to interface cloud web and mobile testing platform providers or applications like Appium

Motivation and Context

In gitlab-ci you cannot add files to services, but I needed to have relay node in selenium hub that is installed for each job

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• [x] I have read the contributing document.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.

[CLAassistant]

All committers have signed the CLA.

[mikk150]

but what if I cannot mount config.toml file in a container(as if you read PR Motivation and Context I even stated that)

[diemol]

but what if I cannot mount config.toml file in a container(as if you read PR Motivation and Context I even stated that)

But with this PR you still need to mount it, what would be the difference?

Also, Relay mode needs a configuration file.

[mikk150]

but what if I cannot mount config.toml file in a container(as if you read PR Motivation and Context I even stated that)

But with this PR you still need to mount it, what would be the difference?

Also, Relay mode needs a configuration file.

no, I do not, as I can use newly created container, configure it using environment variables, and it generates config on the fly just like Chrome image does

edit:// Not only chrome, but appearently also firefox and MicrosoftEdge

[diemol]

Apologies for the delay reviewing this.

I re-read all the thread and I understand the motivation. We also use GitLab-CI internally and through the

services:
  - docker:dind

we are able to mount the files needed for docker.

Have you tried this approach?

[mikk150]

no, I really want to use services(besides, I do not think that dind allows to connect to ci build network, therefore not allowing to add appium image that is connected to android docker image)

[diemol]

I do not understand what this means

I do not think that dind allows to connect to ci build network

[mikk150]

I do not understand what this means

I do not think that dind allows to connect to ci build network

in gitlab-ci you can create a per build network, but it's name is random(hence you cannot connect to it, because you simply do not know it). Doing this removes a lot of networking hassle in docker

[diemol]

Why can't you use dind, and start everything in a docker-compose file? With that approach you will also have the setup working locally.

[mikk150]

Why can't you use dind, and start everything in a docker-compose file? With that approach you will also have the setup working locally.

can you use docker layer caching in dind? I think that pulling couple of gigs of docker images just to run tests gets really expensive fast.

[diemol]

I did not know if that was possible but I went online and searched that. I got this: https://stackoverflow.com/questions/65517744/how-do-i-cache-in-gitlab-ci-while-building-docker-images-with-dockerdind https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#make-docker-in-docker-builds-faster-with-docker-layer-caching

Seems it is possible, what do you think?

[mikk150]

There really is no caching there(no difference from pulling images again every time, since this is what these examples do).

The way I do it is that images are pulled to runners docker instance, therefore they are cached there as long as there is room.

if I cannot cache, each job would have to pull around 5GB of images(Takes a lot of bandwith, nevermind that dockerhub has limits), extract them(Takes a lot of time). Pushing them to gitlab's cache would also have exactly the same issues

[diemol]

I've read the whole conversation again, and I believe the main issue is that this PR is not adding a feature which is being requested widely by the user community.

These docker images tries offer "general" features and avoids corner cases. Based on the GitHub issues and chat conversations we track, having an image for the Relay feature has never come up.

In addition, this would be one more image to maintain, and with the low number of people around, it just ends up as more work for the team.

On the other hand, we could also improve this PR and merge it. Then measure for a couple of months how many pulls the image gets, and if the number is low, we would remove it.

What do you think, @mikk150? Also, are you already building the image yourself in a fork and using it in your own environment?

[mikk150]

So, I currently build this container myself based on selenium/base images, images can be found here: https://gitlab.com/traffic_control/docker-containers/selenium-node-relay/container_registry/3029954

I use it like this:

  services:
    - name: registry.gitlab.com/traffic_control/docker-containers/redroid-chrome/11.0.0:latest
      alias: redroid
    - name: selenium/hub:4
      alias: selenium
    - name: appium/appium
      alias: appium
      variables:
        CHROMEDRIVER_AUTODOWNLOAD: "true"
        REMOTE_ADB: "true"
        ANDROID_DEVICES: "redroid"
        BROWSER_NAME: chrome
    - name: selenium/node-chrome
      variables:
        SE_EVENT_BUS_HOST: selenium
        SE_EVENT_BUS_PUBLISH_PORT: "4442"
        SE_EVENT_BUS_SUBSCRIBE_PORT: "4443"
    - name: selenium/node-firefox
      variables:
        SE_EVENT_BUS_HOST: selenium
        SE_EVENT_BUS_PUBLISH_PORT: "4442"
        SE_EVENT_BUS_SUBSCRIBE_PORT: "4443"
    - name: registry.gitlab.com/traffic_control/docker-containers/selenium-node-relay:4
      variables:
        SE_EVENT_BUS_HOST: selenium
        SE_EVENT_BUS_PUBLISH_PORT: "4442"
        SE_EVENT_BUS_SUBSCRIBE_PORT: "4443"
        SE_RELAY_HUB: http://appium:4723/wd/hub
        SE_RELAY_STATUS_ENDPOINT: /status
        SE_RELAY_CONFIGS: '["1", "{\"browserName\": \"chrome\", \"platformName\": \"android\", \"appium:platformVersion\": \"11\"}"]'

If you do not want to merge it - fine, I believe in Open-source, and that is why I wanted to merge it to mainline. but if project does not want it, then fine, I cannot force your hand.

Given that you do not get any questions about it(Probably because it is quite esoteric way of using selenium) I do not think it will get many fixes

[diemol]

Thank you for your reply.

Another option would be to just put this image as a repository under the https://github.com/seleniumhq-community org, and you could maintain it. What do you think?

[diemol]

Closing this due to inactivity. If this gets more interest from the community, we'd be happy to revisit.