Selenium (Docker, python, behave) takes hours to complete in CI - selenium

Tests are written with python behave and executed with Docker. Locally on Mac/Windows/Linux all 110 test steps complete under 4 minutes using the same sites whereas on CI agent (AWS) it takes 120-160 mins. Video showed that browser is spinning for about 4 minutes between steps. Is there a way to debug selenium to find out what resource is loading slow?
Selenium DEBUG logging is not helpful. After submit it took 4 minutes for a POST request to complete:
04-Apr-2018 20:13:01 DEBUG:selenium.webdriver.remote.remote_connection:POST http://127.0.0.1:4444/wd/hub/session/a6975e2107e574693fb48f21420c1850/element {"using": "id", "value": "submit", "sessionId": "a6975e2107e574693fb48f21420c1850"}
04-Apr-2018 20:13:01 DEBUG:selenium.webdriver.remote.remote_connection:Finished Request
04-Apr-2018 20:13:01 DEBUG:selenium.webdriver.remote.remote_connection:POST http://127.0.0.1:4444/wd/hub/session/a6975e2107e574693fb48f21420c1850/element/0.7198908368495902-4/click {"id": "0.7198908368495902-4", "sessionId": "a6975e2107e574693fb48f21420c1850"}
04-Apr-2018 20:17:00 DEBUG:selenium.webdriver.remote.remote_connection:Finished Request
docker-compose.yml:
version: '3.4'
services:
test:
build:
context: .
image: qa-automation
network_mode: host
environment:
LOCAL: "false"
BROWSER: "${TEST_BROWSER:-chrome}"
SERVER: "${TEST_URL:-https://example.com}"
selenium:
image: elgalu/selenium:3.11.0-p5
shm_size: 2g
ports:
- 4444:24444
- 6000:25900
environment:
SCREEN_WIDTH: 1920
SCREEN_HEIGHT: 1080
TZ: "US/Central"
VIDEO_FILE_NAME: "${TEST_BROWSER:-chrome}"
volumes:
- ./target/videos:/videos
Dockerfile:
FROM python:3.6.4-alpine3.7
# Install utilities
RUN apk --update --no-cache add bash curl git && rm -rf /var/cache/apk/*
ENV PYTHONUNBUFFERED 1
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
# see .dockerignore
COPY . .
ENTRYPOINT ["bin/docker-entrypoint.sh"]
CMD ["behave"]
requirements.txt:
appdirs==1.4.3
behave==1.2.6
packaging==16.8
pyparsing==2.2.0
requests==2.13.0
selenium==3.11.0
six==1.11.0
test.sh:
#!/usr/bin/env bash
docker-compose up -d selenium
docker-compose exec selenium wait_all_done 30s
docker-compose exec selenium start-video
# run tests
docker-compose build test
docker-compose run test bash -c "behave"
ret_code=$?
echo "===== Auto Tests COMPLETED ====="
# clean up containers
docker-compose exec selenium stop-video
docker-compose exec selenium stop
docker-compose down
exit $ret_code

Related

Nvidia runtime in a gitlab-ci service

I have a service which loads docker daemon docker and I want to utilize nvidia gpus inside this service, I have created an image which has a dockerd as entrypoint and installed nvidia cuda driver but when I am trying to deploy my application for test purposes I am facing errors related with nvidia driver inside the service’s image
docker: Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused “process_linux.go:449: container init caused “process_linux.go:432: running prestart hook 1 caused \“error running hook: exit status 1, stdout: , stderr: nvidia-container-cli: initialization error: driver error: failed to process request\n\”””: unknown.
#image: chatzich/dinvidia
stages:
- test
- package
before_script:
- echo "Before script section"
after_script:
- echo "After script section"
test:
image: chatzich/dinvidia
services:
- name: chatzich/dinvidia
alias: dinvidia
stage: build
variables:
DOCKER_HOST: tcp://dinvidia:2375
DOCKER_DRIVER: overlay2
DOCKER_TLS_CERTDIR: ""
tags:
- gpu
script:
# Build the production image
- echo "Build stage script"
- ldconfig -p | grep nvidia
- docker --version
- docker run --rm --runtime=nvidia nvidia/cuda ldconfig -p | grep nvidia
stage: test
package:
stage: package
script:
# Build the production image
- echo "Package stage script"

Running dockerized Behat BDD Tests using Zalenium ( scalable selenium grid )

I am trying to Run Behat BDD Tests using docksal/behat docker-compose ( ref: https://github.com/docksal/behat
Looking at the Zalenium documentation
Pull docker-selenium
docker pull elgalu/selenium
# Pull Zalenium
docker pull dosel/zalenium
# Run it!
docker run --rm -ti --name zalenium -p 4444:4444 \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /tmp/videos:/home/seluser/videos \
--privileged dosel/zalenium start
# Point your tests to http://localhost:4444/wd/hub and run them
integrating docksal/behat and zelenium is not clear
using. the. following docker-compose.yml
# The purpose of this -test example is for the e2e tests of this project
#
# Usage:
# docker-compose -p grid up --force-recreate
# docker-compose -p grid scale mock=1 hub=1 chrome=3 firefox=3
version: '2.1'
services:
hub:
image: elgalu/selenium
ports:
- ${VNC_FROM_PORT-40650}-${VNC_TO_PORT-40700}:${VNC_FROM_PORT-40650}-${VNC_TO_PORT-40700}
zalenium:
image: "dosel/zalenium"
container_name: zalenium
hostname: zalenium
tty: true
volumes:
- /tmp/videos:/home/seluser/videos
- /var/run/docker.sock:/var/run/docker.sock
privileged: true
ports:
- 4444:4444
command: >
start --desiredContainers 2
--maxDockerSeleniumContainers 8
--screenWidth 800 --screenHeight 600
--timeZone "America/New_York"
--videoRecordingEnabled false
--sauceLabsEnabled false
--browserStackEnabled false
--testingBotEnabled false
--cbtEnabled false
--startTunnel false
behat:
hostname: behat
image: docksal/behat
volumes:
- .:/src
# Run a built-in web server for access to HTML reports
ports:
- 8000:8000
entrypoint: "php -S 0.0.0.0:8000"
# browser:
# hostname: browser
# Pick/uncomment one
# image: selenium/standalone-chrome
#image: selenium/standalone-firefox
I can bring up the following containers:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9a1620da4c71 elgalu/selenium:latest "entry.sh" 4 seconds ago Up 4 seconds 40001/tcp, 50001/tcp zalenium_52g9tn
82975a246be8 elgalu/selenium:latest "entry.sh" 5 seconds ago Up 4 seconds 40000/tcp, 50000/tcp zalenium_fdCCbk
862017957ba1 docksal/behat "php -S 0.0.0.0:8000" 2 days ago Up 8 seconds 0.0.0.0:8000->8000/tcp behat-selenium_behat_1
2da2c165a211 elgalu/selenium "entry.sh" 4 days ago Up 6 seconds 0.0.0.0:40650-40700->40650-40700/tcp behat-selenium_hub_1
10df443d8378 dosel/zalenium "entry.sh start --de…" 4 days ago Up 8 seconds 0.0.0.0:4444->4444/tcp, 4445/tcp zalenium
now looking at run-behat in examples directory:
basically executing
$docker exec $(docker-compose ps -q behat) behat --colors --format=pretty --out=std --format=html --out=html_report "$#"
I get an error:
Error response from daemon: Container 411c6b89d8f382a64ed567dbe4d02a2840f06d4778f1ce7bcf955e720d96ab02 is not running
whereas:
$ docker-compose ps -q behat
411c6b89d8f382a64ed567dbe4d02a2840f06d4778f1ce7bcf955e720d96ab02
Perhaps in behat.yml wd_host: http://localhost:4444/wd/hub
it should not point to localhost, but rather the hub? since wd_host should point to the selenium grid running in the container?
This
hub:
image: elgalu/selenium
ports:
- ${VNC_FROM_PORT-40650}-${VNC_TO_PORT-40700}:${VNC_FROM_PORT-40650}-${VNC_TO_PORT-40700}
is not needed at all.
Just point your tests to the zalenium service, since you are using docker-compose.
http://zalenium:4444/wd/hub

How do you set up selenium grid using docker on windows?

Steps I have taken already
1. Downloaded and installed Docker Toolbox for windows
2. Open Docker Quickstart terminal
3. Entered the below commands to pull the docker images from dockerhub and run them
docker pull selenium/hub
docker pull selenium/node-chrome
docker pull selenium/node-firefox
docker run -d -P \--name hub selenium/hub
docker run -d --link hub:hub -P \--name chrome selenium/node-chrome
docker run -d --link hub:hub -P \--name firefox selenium/node-firefox
It appears to be running when I type docker logs hub but I am unable to route my tests to the hub's address on the virtualbox VM using seleniumAddress in my conf.js file or see it using http://ipAddress:4444/grid/console .
Ideally I would like to use this set up to expand the amount of parallel test instances I can run.
Unfortunately the selenium docker image might be broken since 4 days ago but you can try my alternative one:
Pull the image and run as many containers as you need
docker pull elgalu/selenium
docker run -d --name=grid4 -p 4444:24444 -p 5904:25900 \
-v /dev/shm:/dev/shm -e VNC_PASSWORD=hola elgalu/selenium
docker run -d --name=grid5 -p 4445:24444 -p 5905:25900 \
-v /dev/shm:/dev/shm -e VNC_PASSWORD=hola elgalu/selenium
docker run -d --name=grid6 -p 4446:24444 -p 5906:25900 \
-v /dev/shm:/dev/shm -e VNC_PASSWORD=hola elgalu/selenium
Wait until the all the grids started properly before starting the tests (Optional but recommended)
docker exec grid4 wait_all_done 30s
docker exec grid5 wait_all_done 30s
docker exec grid6 wait_all_done 30s
After this, Selenium should be up and running at http://localhost:4444/wd/hub. Open the url in your browser to confirm it is running.
If you are using Mac (OSX) or Microsoft Windows localhost won't work! Find out the correct IP through boot2docker ip or docker-machine ip default.
So set the selenium port accordingly for each of your test:
1st test should connect to http://ipAddress:4444/wd/hub
2nd test to http://ipAddress:4445/wd/hub
3rd test to http://ipAddress:4446/wd/hub
You can run as many as your hardware can take.
Take a look at the Protractor Cookbook w/ Docker. The instructions are listed step-by-step using selenium-grid and docker compose. Docker-selenium issue #208 has been fixed.
So you'll need to pull down the latest images*:
docker pull selenium/hub:latest
docker pull selenium/node-chrome-debug:latest
Start the selenium grid:
docker run -d -p 4444:4444 --name selenium-hub selenium/hub:latest
Then add selenium nodes. I like to use the chrome-debug and firefox-debug versions to VNC to watch the tests.
docker run -d -p <port>:5900 --link selenium-hub:hub selenium/node-chrome-debug:latest
After linking your selenium grid, this should be enough to run your Protractor test using the seleniumAddress: 'http://localhost:4444/wd/hub'.
For debugging, find the VNC port for the container with:
docker port <container-name or container-id> 5900
and access it via VNC Viewer.
Note:
At the time of this writing, 'latest' appears to be tied to a ~2.53.1 version of selenium server. As of Protractor 4.0.11 (the latest version of Protractor), this is the supported version that should be used. Note that the instructions on the Selenium-docker GitHub appear to be for tailored for selenium server 3.0.1.
You can use below compose file to setup grid and access via VNC
**# To execute this docker-compose yml file use docker-compose -f up
**# Add the "-d" flag at the end for deattached execution****
version: '2'
services:
firefoxnode:
image: selenium/node-firefox-debug
volumes:
- /dev/shm:/dev/shm
depends_on:
- hub
environment:
HUB_HOST: hub
ports:
- "32772:5900"
chromenode:
image: selenium/node-chrome-debug
volumes:
- /dev/shm:/dev/shm
depends_on:
- hub
environment:
HUB_HOST: hub
ports:
- "32773:5900"
hub:
image: selenium/hub
ports:
- "4444:4444"
command I use:
docker-compose -f .\docker-compose.yml up -d
Source :
https://github.com/SeleniumHQ/docker-selenium

Use GitLab CI to run tests locally?

If a GitLab project is configured on GitLab CI, is there a way to run the build locally?
I don't want to turn my laptop into a build "runner", I just want to take advantage of Docker and .gitlab-ci.yml to run tests locally (i.e. it's all pre-configured). Another advantage of that is that I'm sure that I'm using the same environment locally and on CI.
Here is an example of how to run Travis builds locally using Docker, I'm looking for something similar with GitLab.
Since a few months ago this is possible using gitlab-runner:
gitlab-runner exec docker my-job-name
Note that you need both docker and gitlab-runner installed on your computer to get this working.
You also need the image key defined in your .gitlab-ci.yml file. Otherwise won't work.
Here's the line I currently use for testing locally using gitlab-runner:
gitlab-runner exec docker test --docker-volumes "/home/elboletaire/.ssh/id_rsa:/root/.ssh/id_rsa:ro"
Note: You can avoid adding a --docker-volumes with your key setting it by default in /etc/gitlab-runner/config.toml. See the official documentation for more details. Also, use gitlab-runner exec docker --help to see all docker-based runner options (like variables, volumes, networks, etc.).
Due to the confusion in the comments, I paste here the gitlab-runner --help result, so you can see that gitlab-runner can make builds locally:
gitlab-runner --help
NAME:
gitlab-runner - a GitLab Runner
USAGE:
gitlab-runner [global options] command [command options] [arguments...]
VERSION:
1.1.0~beta.135.g24365ee (24365ee)
AUTHOR(S):
Kamil Trzciński <ayufan#ayufan.eu>
COMMANDS:
exec execute a build locally
[...]
GLOBAL OPTIONS:
--debug debug mode [$DEBUG]
[...]
As you can see, the exec command is to execute a build locally.
Even though there was an issue to deprecate the current gitlab-runner exec behavior, it ended up being reconsidered and a new version with greater features will replace the current exec functionality.
Note that this process is to use your own machine to run the tests using docker containers. This is not to define custom runners. To do so, just go to your repo's CI/CD settings and read the documentation there. If you wanna ensure your runner is executed instead of one from gitlab.com, add a custom and unique tag to your runner, ensure it only runs tagged jobs and tag all the jobs you want your runner to be responsible of.
I use this docker-based approach:
Edit: 2022-10
docker run --entrypoint bash --rm -w $PWD -v $PWD:$PWD -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest -c 'git config --global --add safe.directory "*";gitlab-runner exec docker test'
For all git versions > 2.35.2. You must add safe.directory within the container to avoid fatal: detected dubious ownership in repository at.... This also true for patched git versions < 2.35.2. The old command will not work anymore.
Details
0. Create a git repo to test this answer
mkdir my-git-project
cd my-git-project
git init
git commit --allow-empty -m"Initialize repo to showcase gitlab-runner locally."
1. Go to your git directory
cd my-git-project
2. Create a .gitlab-ci.yml
Example .gitlab-ci.yml
image: alpine
test:
script:
- echo "Hello Gitlab-Runner"
3. Create a docker container with your project dir mounted
docker run -d \
--name gitlab-runner \
--restart always \
-v $PWD:$PWD \
-v /var/run/docker.sock:/var/run/docker.sock \
gitlab/gitlab-runner:latest
(-d) run container in background and print container ID
(--restart always) or not?
(-v $PWD:$PWD) Mount current directory into the current directory of the container - Note: On Windows you could bind your dir to a fixed location, e.g. -v ${PWD}:/opt/myapp. Also $PWD will only work at powershell not at cmd
(-v /var/run/docker.sock:/var/run/docker.sock) This gives the container access to the docker socket of the host so it can start "sibling containers" (e.g. Alpine).
(gitlab/gitlab-runner:latest) Just the latest available image from dockerhub.
4. Execute with
Avoid fatal: detected dubious ownership in repository at... More info
docker exec -it -w $PWD gitlab-runner git config --global --add safe.directory "*"
Actual execution
docker exec -it -w $PWD gitlab-runner gitlab-runner exec docker test
# ^ ^ ^ ^ ^ ^
# | | | | | |
# (a) (b) (c) (d) (e) (f)
(a) Working dir within the container. Note: On Windows you could use a fixed location, e.g. /opt/myapp.
(b) Name of the docker container
(c) Execute the command "gitlab-runner" within the docker container
(d)(e)(f) run gitlab-runner with "docker executer" and run a job named "test"
5. Prints
...
Executing "step_script" stage of the job script
$ echo "Hello Gitlab-Runner"
Hello Gitlab-Runner
Job succeeded
...
Note: The runner will only work on the commited state of your code base. Uncommited changes will be ignored. Exception: The .gitlab-ci.yml itself does not have be commited to be taken into account.
Note: There are some limitations running locally. Have a look at limitations of gitlab runner locally.
I'm currently working on making a gitlab runner that works locally.
Still in the early phases, but eventually it will become very relevant.
It doesn't seem like gitlab want/have time to make this, so here you go.
https://github.com/firecow/gitlab-runner-local
If you are running Gitlab using the docker image there: https://hub.docker.com/r/gitlab/gitlab-ce, it's possible to run pipelines by exposing the local docker.sock with a volume option: -v /var/run/docker.sock:/var/run/docker.sock. Adding this option to the Gitlab container will allow your workers to access to the docker instance on the host.
The GitLab runner appears to not work on Windows yet and there is an open issue to resolve this.
So, in the meantime I am moving my script code out to a bash script, which I can easily map to a docker container running locally and execute.
In this case I want to build a docker container in my job, so I create a script 'build':
#!/bin/bash
docker build --pull -t myimage:myversion .
in my .gitlab-ci.yaml I execute the script:
image: docker:latest
services:
- docker:dind
before_script:
- apk add bash
build:
stage: build
script:
- chmod 755 build
- build
To run the script locally using powershell I can start the required image and map the volume with the source files:
$containerId = docker run --privileged -d -v ${PWD}:/src docker:dind
install bash if not present:
docker exec $containerId apk add bash
Set permissions on the bash script:
docker exec -it $containerId chmod 755 /src/build
Execute the script:
docker exec -it --workdir /src $containerId bash -c 'build'
Then stop the container:
docker stop $containerId
And finally clean up the container:
docker container rm $containerId
Another approach is to have a local build tool that is installed on your pc and your server at the same time.
So basically, your .gitlab-ci.yml will basically call your preferred build tool.
Here an example .gitlab-ci.yml that i use with nuke.build:
stages:
- build
- test
- pack
variables:
TERM: "xterm" # Use Unix ASCII color codes on Nuke
before_script:
- CHCP 65001 # Set correct code page to avoid charset issues
.job_template: &job_definition
except:
- tags
build:
<<: *job_definition
stage: build
script:
- "./build.ps1"
test:
<<: *job_definition
stage: test
script:
- "./build.ps1 test"
variables:
GIT_CHECKOUT: "false"
pack:
<<: *job_definition
stage: pack
script:
- "./build.ps1 pack"
variables:
GIT_CHECKOUT: "false"
only:
- master
artifacts:
paths:
- output/
And in nuke.build i've defined 3 targets named like the 3 stages (build, test, pack)
In this way you have a reproducible setup (all other things are configured with your build tool) and you can test directly the different targets of your build tool.
(i can call .\build.ps1 , .\build.ps1 test and .\build.ps1 pack when i want)
I am on Windows using VSCode with WSL
I didn't want to register my work PC as a runner so instead I'm running my yaml stages locally to test them out before I upload them
$ sudo apt-get install gitlab-runner
$ gitlab-runner exec shell build
yaml
image: node:10.19.0 # https://hub.docker.com/_/node/
# image: node:latest
cache:
# untracked: true
key: project-name
# key: ${CI_COMMIT_REF_SLUG} # per branch
# key:
# files:
# - package-lock.json # only update cache when this file changes (not working) #jkr
paths:
- .npm/
- node_modules
- build
stages:
- prepare # prepares builds, makes build needed for testing
- test # uses test:build specifically #jkr
- build
- deploy
# before_install:
before_script:
- npm ci --cache .npm --prefer-offline
prepare:
stage: prepare
needs: []
script:
- npm install
test:
stage: test
needs: [prepare]
except:
- schedules
tags:
- linux
script:
- npm run build:dev
- npm run test:cicd-deps
- npm run test:cicd # runs puppeteer tests #jkr
artifacts:
reports:
junit: junit.xml
paths:
- coverage/
build-staging:
stage: build
needs: [prepare]
only:
- schedules
before_script:
- apt-get update && apt-get install -y zip
script:
- npm run build:stage
- zip -r build.zip build
# cache:
# paths:
# - build
# <<: *global_cache
# policy: push
artifacts:
paths:
- build.zip
deploy-dev:
stage: deploy
needs: [build-staging]
tags: [linux]
only:
- schedules
# # - branches#gitlab-org/gitlab
before_script:
- apt-get update && apt-get install -y lftp
script:
# temporarily using 'verify-certificate no'
# for more on verify-certificate #jkr: https://www.versatilewebsolutions.com/blog/2014/04/lftp-ftps-and-certificate-verification.html
# variables do not work with 'single quotes' unless they are "'surrounded by doubles'"
- lftp -e "set ssl:verify-certificate no; open mediajackagency.com; user $LFTP_USERNAME $LFTP_PASSWORD; mirror --reverse --verbose build/ /var/www/domains/dev/clients/client/project/build/; bye"
# environment:
# name: staging
# url: http://dev.mediajackagency.com/clients/client/build
# # url: https://stg2.client.co
when: manual
allow_failure: true
build-production:
stage: build
needs: [prepare]
only:
- schedules
before_script:
- apt-get update && apt-get install -y zip
script:
- npm run build
- zip -r build.zip build
# cache:
# paths:
# - build
# <<: *global_cache
# policy: push
artifacts:
paths:
- build.zip
deploy-client:
stage: deploy
needs: [build-production]
tags: [linux]
only:
- schedules
# - master
before_script:
- apt-get update && apt-get install -y lftp
script:
- sh deploy-prod
environment:
name: production
url: http://www.client.co
when: manual
allow_failure: true
The idea is to keep check commands outside of .gitlab-ci.yml. I use Makefile to run something like make check and my .gitlab-ci.yml runs the same make commands that I use locally to check various things before committing.
This way you'll have one place with all/most of your commands (Makefile) and .gitlab-ci.yml will have only CI-related stuff.
I have written a tool to run all GitLab-CI job locally without have to commit or push, simply with the command ci-toolbox my_job_name.
The URL of the project : https://gitlab.com/mbedsys/citbx4gitlab
Years ago I build this simple solution with Makefile and docker-compose to run the gitlab runner in docker, you can use it to execute jobs locally as well and should work on all systems where docker works:
https://gitlab.com/1oglop1/gitlab-runner-docker
There are few things to change in the docker-compose.override.yaml
version: "3"
services:
runner:
working_dir: <your project dir>
environment:
- REGISTRATION_TOKEN=<token if you want to register>
volumes:
- "<your project dir>:<your project dir>"
Then inside your project you can execute it the same way as mentioned in other answers:
docker exec -it -w $PWD runner gitlab-runner exec <commands>..
I recommend using gitlab-ci-local
https://github.com/firecow/gitlab-ci-local
It's able to run specific jobs as well.
It's a very cool project and I have used it to run simple pipelines on my laptop.

How to fix the webdriver config so the test result won't be differ between computers

I write the test on Mac and everything works well.
Then I migrated the test script to server's (ubuntu on Linode) docker container.
The test was failed,
#driver.current_url will show me https://m.flyscoot.com/
but actually I gave the url http://www.flyscoot.com/index.php/en/ to open.
My test was failed by unexpectedly redirected to https://m.flyscoot.com/
I've no idea why this happened?
I guess the web driver was be thought a mobile version browser.
How could I cheat the website so that I can get the identical test result ?
Test failed environment is running on selenium/node-firefox-debug and selenium/hub from this repo https://github.com/SeleniumHQ/docker-selenium
Dockerfile
FROM selenium/node-firefox-debug
....
CMD ["/bin/bash", "/opt/bin/entry_point.sh"]
docker-compose
hub:
image: selenium/hub
ports:
- 4444:4444
web:
build: .
volumes:
- .:/crawler
ports:
- 5900:5900
links:
- hub:hub
entry_point.sh
#!/bin/bash
# RUN THE CRON JOB
export GEOMETRY="$SCREEN_WIDTH""x""$SCREEN_HEIGHT""x""$SCREEN_DEPTH"
xvfb-run --server-args="$DISPLAY -screen 0 $GEOMETRY -ac +extension RANDR" \
java -jar /opt/selenium/selenium-server-standalone.jar \
-role node \
-hub http://$HUB_1_PORT_4444_TCP_ADDR:$HUB_1_PORT_4444_TCP_PORT/grid/register \
-browser browserName=firefox
--background