By Private Profile fd6a0afe on 2017-06-18 16:55 in GSoC 17 Parallel Testing

Date: 14th June 2017

Time: 15:00 (UTC / GMT)

Meeting was attended by: Andrei Isac, Tito Alvarez

 

Summary:

1. Work report of the last week (what was achieved, what's in progress, etc)

2. Selenium container execution

3. Network vs DNS in the Virtualisation project

4. New challenge: call scripts inside selenium container

 

 

 

Topics:

1) Work report of the last week

 

I finally have the working testing environment, consequently all the pairs of Joomla+PHP are working. The Joomla installation is completed and each has 3 users, including an admin user required for installing Joomla "admin", "admin"

I thought about importing the users myself, by doing an SQL dump from my locally installed Joomla, but it seems that Niels already had that in mind, and I have found similar dumps in the virtualisation project. I have updated the code to include all of this, and now its working.

 

What I have found:

• The proxy needs to be on a port different that 80 (the default)

• The servers work best only with mysqli, not mysql, with mysql half of them don't connect to the database

• I have tried to manually run tests on one of the server, by using the weblinks repo, in order to see how that works ,but I have not yet managed to configure my local environment, It seems that codecept does not see my Firefox installation.

 

 

2) Selenium container execution

 

The selenium container execution challenge represent the problem of making the container execute a specific task by a remote command on a specific server

 

The first part (specific task) is the one that needs to be supported by robo. This part  should come after the task-selection algorithm is done, so the queue tells the container which task it's going to run. And the second part (specific server) is similar, it should come as a parameter, to modify the codeception yml config file, also given by the queue, from the task-selection algorithm.

 

We should use our own selenium containers, starting with the Firefox one, which is 100% running and compatible with the provided Robo Files

 

The real important part (right now) about it is the $this->runTestSuites($opts); part because that one needs to be defined in each extension right now, in our case:

 

Right now you cannot pass any options, except the environment and debug

 

The desired final command would be something like this: /vendor/bin/robo run:tests j37_54 install

 

 

3) Network vs DNS in the Virtualisation project

 

Docker network agreement because of the isolation and using the internal DNS when running test, so it needs to be improved in 2 points:

1. The Docker compose file needs to be able to create a network and make all the created containers join that network

2. In the Apache conf files, we need to alter them so that they have a name and an alias (which are similar), so they can be something like:

<vhost> = <phpversion>_<joomlaversion>

<vhost>.<testid>.dev = <phpversion>_<joomlaversion>.<randomtestid>.dev

the <randomtestid> can be the network name too

 

If we do that we gain two points actually:

1. We use the Docker network for internal communication (by simply using <vhost>) between containers

2. We have the ability of using the proxy for local tests

 

Due to the fact that we have multiple Joomla installations in the same Apache server we may have problems, therefore we should investigate that first then.

 

First solution would be by using subdomains and the second solution would be using multiple names for one container. If none are allowed, then Docker Networking is not compatible multiple Joomla installations per container and we will need to decide if we will prefer Docker network or better performance.

 

The decision is still in place, I shall to prototype the proposed solution as top priority.

 

 

4) New challenge: call scripts inside selenium container

 

First solution, docker exec. This implies to have a daemon running in the selenium container, preventing it from dying, and listening to those calls. With docker exec, the command is called from the host. It is theoretically speaking with some work on the startup scripts.

 

The other option is to basically wrap each selenium container in a web server, then we can call it by POST, it's better, has some advantages, the containers will be 100% decoupled and independent, but may take longer to implement. This complies to the microservices architecture, so each selenium container would be a microservice.

 

 

In the end, the decision is between making selenium container a microservice or developing our own bash-based daemon.