General Docker image for executing headless Google Chrome or Firefox Protractor e2e test cases in a Docker container. The created image does not contain any test code or project. This is the environment for running Protractor test cases. So this image is test project independent.
The Dockerfile was design based on the following projects:
- Protractor and headless Chrome on Docker or Docker image of Protractor with headless Chrome
- docker-protractor
- Protractor-Firefox-Headless-Docker
To run your test cases in this image
- Pull the
hortonworks/docker-e2e-protractor
image from DockerHub - If you have any environment variable which is used for your test project, provide here environment file.
- The Protractor configuration file is vital for the Docker image. Add your e2e test configuration JS file (for example
e2e.conf.js
). Beside this you can provide additional parameters here for protractor. - You can see some example for execute your protractor tests in this Docker container:
docker run -it --rm --name protractor-runner -v $(PWD):/protractor/project hortonworks/docker-e2e-protractor e2e.conf.js docker run -it --rm --name protractor-runner --env-file utils/testenv -v $(PWD):/protractor/project hortonworks/docker-e2e-protractor e2e.conf.js --suite smoke docker run -it --rm --name protractor-runner -e USERNAME=teszt.elek -e PASSWORD=Teszt12 -v $(PWD):/protractor/project hortonworks/docker-e2e-protractor e2e.conf.js --suite regression docker run -it --rm --name protractor-runner --privileged --net=host -v /dev/shm:/dev/shm -v $(PWD):/protractor/project hortonworks/docker-e2e-protractor e2e.conf.js --suite smoke
utils/testenv
the location (full path) of thetestenv
file on your machine. This file can contain environment variables for your new container.USERNAME=teszt.ele
a single environment variable that is passed for the new container.$(PWD)
orpwd
the root folder of your Protractor test project:- For example the local folder where the your functional E2E test project has been cloned from GitHub.
- The use of PWD is optional, you do not need to navigate to the Protractor test project root. If it is the case, you should add the full path of the root folder instead of the
$(PWD)
.
e2e.conf.js --suite regression
in case of you defined test suites in your Protractor configuration, you can add these here
Advanced options and information
Protractor direct connect
Protractor can test directly using Chrome Driver or Firefox Driver, bypassing any Selenium Server. The advantage of direct connect is that your test project start up and run faster.
To use this, you should change your protractor configuration file as desbribed in the related Protractor Documentation:
directConnect: true
If this is true, settings for seleniumAddress and seleniumServerJar will be ignored. If you attempt to use a browser other than Chrome or Firefox an error will be thrown.
No sandbox for Google Chrome
Chrome does not support to running it in container. So you need to start the Chrome Driver with --no-sandbox
argument to avoid errors.
Also in the Protractor configuration file:
capabilities: {
'browserName': 'chrome',
/**
* Chrome is not allowed to create a SUID sandbox when running inside Docker
*/
'chromeOptions': {
'args': [
'no-sandbox',
'--disable-web-security'
]
}
},
You can find additional setup configurations in the related Protractor Documentation
--privileged
Chrome uses sandboxing, therefore if you try and run Chrome within a non-privileged container you will receive the following message:
"Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted".
The --privileged
flag gives the container almost the same privileges to the host machine resources as other processes running outside the container, which is required for the sandboxing to run smoothly.
Based on the Webnicer project.
Run tests in CI
The project's Makefile contains several rules what you can use with your CI jobs. For example:
run-ci:
./scripts/e2e-gui-test.sh
As you can see here the project contains a predefined bash script to automate launch and test environment setup before tests execution.
If you do not want to use Make, here is a code snippet that you can apply:
echo "Refresh the Test Runner Docker image"
docker pull hortonworks/docker-e2e-protractor
export TEST_CONTAINER_NAME=gui-e2e
echo "Checking stopped containers"
if [[ -n "$(docker ps -a -f status=exited -f status=dead -q)" ]]; then
echo "Delete stopped containers"
docker rm $(docker ps -a -f status=exited -f status=dead -q)
else
echo "There is no Exited or Dead container"
fi
echo "Checking " $TEST_CONTAINER_NAME " container is running"
if [[ "$(docker inspect -f {{.State.Running}} $TEST_CONTAINER_NAME 2> /dev/null)" == "true" ]]; then
echo "Delete the running " $TEST_CONTAINER_NAME " container"
docker rm -f $TEST_CONTAINER_NAME
fi
BASE_URL_RESPONSE=$(curl -k --write-out %{http_code} --silent --output /dev/null $BASE_URL/sl)
echo $BASE_URL " HTTP status code is: " $BASE_URL_RESPONSE
if [[ $BASE_URL_RESPONSE -ne 200 ]]; then
echo $BASE_URL " Web GUI is not accessible!"
RESULT=1
else
docker run -i \
--privileged \
--rm \
--name $TEST_CONTAINER_NAME \
--env-file $ENVFILE \
-v $(pwd):/protractor/project \
-v /dev/shm:/dev/shm \
hortonworks/docker-e2e-protractor e2e.conf.js --suite $TEST_SUITE
RESULT=$?
fi
Makefile
We created a very simple Makefile to be able build and run easily our Docker image:
make build
then
make run
or you can run the above commands in one round:
make all
The rules are same as in case of To run your test cases in this image.
In-memory File System /dev/shm (Linux only)
Docker has hardcoded value of 64MB for /dev/shm
. Error can be occurred, because of page crash on memory intensive pages. The easiest way to mitigate the problem is share /dev/shm
with the host.
docker run -it --rm --name protractor-runner --env-file utils/testenv -v /dev/shm:/dev/shm -v $(PWD):/protractor/project sequenceiq/protractor-runner
The size of /dev/shm
in the Docker container can be changed when container is made with option --shm-size
.
For Mac OSX users this conversation can be useful.
Based on the Webnicer project.
--net=host
This options is required only if the dockerised Protractor is run against localhost on the host.
Imagine this scenario:
Run an http test server on your local machine, let's say on port 8000. You type in your browser http://localhost:8000 and everything goes smoothly. Then you want to run the dockerised Protractor against the same localhost:8000. If you don't use --net=host
the container will receive the bridged interface and its own loopback and so the localhost within the container will refer to the container itself. Using --net=host
you allow the container to share host's network stack and properly refer to the host when Protractor is run against localhost.
Based on the Webnicer project.