In order to reuse the test server to the external modules, it is much
easier to share the common configurations (scripts) and test data via
Dockerfile. In addition, the external module can create more layers
depending on their needs. Therefore, supporting multi-stage builds is
needed. The disadvantage is that the docker-compose needs to re-build
the images every time. However, it is just a one-time effort. If the
Dockerfile doesn't get changed, the extra build time can be ignored.
Because of multi-stage builds, the test server will keep a Dockerfile at
least. Therefore, the volume sharing is no more needed. The test data of
a service can be added into the images by using COPY/ADD commands.
NOTE:
This patch relies on docker-compose v1.21.0 (docker-compose build now
supports the use of Dockerfile from outside the build context).
Change-Id: Ib3f6a5fcf6979732ae8a40a494a1360fca4ac7bf
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
On Windows and macOS, the containers are deployed into a virtual
machine using the host network. All the containers share the same
hostname (qt-test-server), and they are connected to the same network
domain (local).
When running test in such platforms, use the single-name SSL certificate
(qt-test-server.local) for SSL related tests.
Change-Id: Idf33e01e8dd8814510d848b87b59b5fc0edc903e
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
Setting the fall-back network interface of danted's environment to eth0
by docker-compose file is redundant because the value of danted's
configuration (danted.conf) has been set to eth0 by default.
Change-Id: If2dea8daaf851577a573e201e9c50684916e5206
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
For macOS and Windows, the test-server containers are deployed in the
VirtualBox (Boot2Docker). Because Boot2Docker is a lightweight Linux
distribution made specifically to run Docker containers, it doesn't
install avahi-daemon and support mDNS discovery.
To resolve this problem, Docker compose file supports "extra_hosts" to
add hostname mappings inside containers.
BFAIL items:
tst_QNetworkReply::headFromHttp(...+proxy...) (ten cases)
tst_QNetworkReply::ioGetWithManyProxies(http-on-http)
tst_QNetworkReply::ioGetWithManyProxies(http-on-http2)
tst_QNetworkReply::ioGetWithManyProxies(http-on-multiple-http)
tst_QNetworkReply::ioGetWithManyProxies(http-on-http+socks)
tst_QNetworkReply::ioGetWithManyProxies(http-on-ftp+http+socks)
tst_QNetworkReply::ioPostToHttpFromSocket(...+proxy) (twelve cases)
tst_QNetworkReply::ioPostToHttpFromSocket(...+proxyauth) (ten cases)
Change-Id: Iec55966a9b5f191b7446985a15b49a8b09dcf407
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
Docker compose file supports variable substitution. When running
docker-compose up, Compose looks for the environment variables from
shell and substitutes the values at runtime.
Change-Id: I5255ead82276fac7db24ee74af453f83ca20bbe6
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This update is used to free the dependencies of the specific Ubuntu
packages. It ensures that test server is using the latest version of the
Ubuntu packages to test network changes.
Change-Id: I3257f435e6da02e3c6d5a141ece9c5d025e13065
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
There is no docker bridge on macOS. Docker document recommends using
port mapping to connect to a container; but it causes a port conflict
if the user is running a service that binds the same port on the host.
An alternative solution is to deploy the docker environment into
VirtualBox and use the host network option.
Task-number: QTQAINFRA-2293
Change-Id: I05dc65c5f8b4be7a1b1874a4ec7c034cc68679ca
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
