With the end of GSoC coming to a near after this long journey it is time to make a balance of what the whole experience has been so far.
I’ll go over what has been accomplished, how were the interactions, the difficulties encountered, final steps for GSoC and prospects for the near future of this project.
Balance of the whole experience
Coming in to GSoC I wasn’t really sure what it really was, because I have never had an experience like this and it was a big project to be built from the ground up, it was awe inspiring at first and to be honest I felt a bit overwhelmed and scared at times.
I have to say, it would have been infinitely harder without the help of my team (Niels Braczek, Tito Alvarez, Ashan Fernando, Puneet Kala, Yves Hoppe, Tobias Zulauf, Astrid Günther) as well as the help and support of my family and closest friends whom were my cornerstone as the project progressed.
It took a while to get things on track because a project from the ground up has a lot of figuring out to do along the way. Even near the end there is so much still to figure out. We had weekly meetings from the beginning until now in order to discuss the progress so far, decide on paths to take and decide on the next steps being able to always keep track on the project and ensure everything is working fine and on time.
With the help and support of my team I’ve managed to go through each stage step by step giving my best to have the project ready on time.
I wholeheartedly recommend any student to go ahead and take on a project on GSoC (Joomla! preferably). it was a hard path and a hard project, I had my difficulties but the gains far outweigh the losses and I don’t mean the monetary gains at all, that is just a bonus on top of everything else.
I’ve managed to learn so much since I began, several technologies, planning and architecting a system/project, look at a large code base, analyse it, build the autonomy to learn new things, work together as a team, manage my time in a more efficient way, improve my programming skills, meet so many amazing people in this awesome community and contribute to it.
It is so refreshing to see such a vibrant and multicultural community as this one where everyone is nice to each other and everyone helps each other.
Overall it is an extraordinarily enriching experience that everyone should try in my opinion.
Accomplishments and progress so far
Going over the objectives, the first phase I had to get the Jenkins environment and settings ready in order to build the PRs/commits and keep the code up to date in the host, in phase two I had to get the multi-container docker environment ready for hosting Joomla! Instances, and in the final phase I had to get the tests requests website done and connect the 3 parts in order to allow the user to request a test on the website and have an instance generated for the PR given the PHP version in order for the user to test that PR.
Since the first blogpost a lot has changed regarding the scope of this project and the choices to make. I’m going to go over those changes a bit and the work I’ve accomplished so far for the project.
So after having Jenkins ready, building PRs and commits to the repository, phase 2 was about having the multi-container environment ready to host the Joomla! Instances. At the beginning the team thought that having Dockerfiles for each PHP version and repo branch combination would be the best choice and having scripts working in order to generate the dockerfiles to be used later with Virtualization project and PatchTester.
After a few discussions and a weighing of the pros and cons of each approach, the team decided that Virtualization for this project would be overkill and that PatchTester would also not be the best choice because it still has some DB issues to consider.
We started with the docker-compose environment development, Niels Braczek stumbled upon a tool that could be (and has been) useful for this project called Devilbox. It is a highly customizable LAMP and MEAN stack replacement based purely on docker and docker-compose, supporting an unlimited number of projects for which vhosts and DNS records are created automatically.
I took that tool and heavily customized it to allow having containers for 3 PHP versions and a web server attached to each of those which in turn are hidden behind a proxy (Jwilder Nginx Proxy) which distributes the requests according to the PHP version using regular expressions. The only way I found to be able to correctly redirect the requests to the right PHP version container was to place in the first two digits of the instance ID the PHP version (56, 70 or 71) and have a regular expression in the virtual host environment variables for Jwilder proxy to generate the right nginx configuration files.
Besides having the multi-container environment successfully redirecting requests, I also managed to automate Joomla! installation process importing the sql dumps and placing the conf file with the correct info with bash scripts.
With this, I was able to have several Joomla! instances online in the containers as you can see in the next figures:
After having the multi-container environment running, it was time to start building the tests requests website which was the objective for phase 3. For the tests requests website what I had in mind was something along the lines of the Issue Tracker website and use it as base to build the website. Therefore I had to analyze the codebase and with the help of Michael Babker, I managed to figure out some problems I had with setting up and deploying the issue tracker website.
Afterwards, I took the Issue Tracker code and altered it a bit to track only the PRs, inserted an MVC app for the Joomla! instances and added a table for the instances. This way, the user can login with GitHub on the website (https://dbox-tests.ml/) and request the tests choosing the PHP version, the user can then add/remove instances up to 5 active instances max, list the active instances and view the info about each instance.
What is missing is calling the scripts to add instances to the containers upon the add/remove instances buttons click and then create cron jobs to place an expiration date on each instance in order to put the minimum stress on the server as possible.
Difficulties encountered along the way
There were several difficulties along the way as expected, there always are. One of the first difficulties was to learn how to work remotely, to handle time and schedules to be as efficient as possible. In fact, it was just about getting used to it.
Another hard task was analysing large codebases and understanding the code done by many other people so I can figure out how to use it and edit it.
There were some issues with the setup of Jenkins as I’ve mentioned in the first blog post regarding the webhooks.
Regarding the multi-container environment, I had some issues first with going from one PHP version to three. I kept having issues with the web servers and sockets, having to figure out a way to bypass this issue and proxying the requests in a better way. Also I faced some issues with testing and deploying Devilbox on the server after having it successfully working locally. I had to go through a lot of documentation on Devilbox to figure out how everything is done and how to solve the issue.
Then, with the tests requests website, I had some issues configuring the Issue Tracker and with the MySQL dump. There seemed to be an issue with some columns and I wasn’t fully aware of the process to deploy the website but I managed to do it.
Sometimes, these issues dragged me on, were time consuming to try to solve them, and It was sometimes frustrating but thanks to everyone’s help I was able to succeed.
Next steps and prospects for the future
The remaining steps to finish the project are:
- To run the scripts
- To add/remove instances to the multi-container environment on click on the add/remove instances buttons.
Currently there’s a bit of an issue with that because the scripts are meant to be run on the host and the website is in one of the containers. I’ll have either to place the website on the host or make a webservice for the container to communicate with the host to execute the scripts and pass the PR and PHP version data as parameter.
After having this done I’ll have to finish the documentation so that everything is as clear as possible regarding each part of the project. Like that, anyone can replicate/test on their own environment.
After GSoC, I’ll still have to get done with my masters thesis and I’ll hopefully be done with masters in 1 year. Nonetheless I do intend to keep involved with Joomla! and this project in the near future. This project still needs many improvements and I still have a lot of ideas to improve the platform. I hope I can make it the best it can be with the help of everyone and I hope I can contribute to other areas as much as I can.
I also hope I can get to meet all of the mentors, colleagues and as much people from the community as I can when I attend the Joomla! World Conference in Rome so I guess I’ll see you all there!