Hi, I'm wondering is any CI (Continous Integration) service is used for checking ISPConfig code integrity? I'm asking before I would try to arrange something based on Docker or Travis-CI. Is anyone try to setup something? Where or why a not? Thanks for explentations.
There is no continious integration service used yet. there is no special reason why it has not been done yet, just no tme to implement it. It would be great if you could contribute something in this area!
Great! Is using free but commercial CI servers like QuickBuild (which is free up to 16 configurations) an option? If we can find machine to host server and agents of such tool? Or should I approach free SaaS solutions like Travis-CI? There is also an option to request Atlassian tools (Bamboo, JIRA etc...) for non profit organisations. Is behind ISPConfig any non-profit non-religios organisation? We could also try to get Open Source license for Jet Breins PhpStorm IDE http://www.jetbrains.com/phpstorm/buy/buy.jsp. What do you think about that?
Providing a server for that is not a problem and I would prefer if it is hosted on one of our own servers because I dont want to have to switch enviroment just because a external company decides to discontinue their service. Regarding the platform decision, I will have to review the alternatives you posted first as I'am not that familar with them. One thing that I had in mind before your post was to built a set of scripts based on the ispconfig remote api instaed of using a external framework. It should be possible to do a automatic isnstall in a vm, e.g. openvz by script, then use the remote api to add a client, website, ftp user, mail domain, malbox, dns record etc. and then upload a file with this ftp user on the server and query the result, switch trough all php modes and check the results again. Same for email mailbox, send a email trough the local mail system and fetch it with imap and pop3 to test the full email worklflow. I ill have to check out the frameworks if they are able to do all thsi with less code as if we would write the script with a few hundred lines of php code with the remote api.
Instead of using VM we can base on Docker (which is overlay over lxc (linux containers)) which is prefered way to provide sandboxed separated environment to setup operating system and run tests. I will start creating Dockerfile setting up operating system and running existing tests. It might be helpful to know how run: unit/integration/acceptance/end-to-end tests, where they are kept and how to execute them. I will search wiki and forum and try find such information. However any help will be appriciated. I'm starting work on that on my fork repository here: http://git.ispconfig.org/jan.koprowski/ispconfig3 My builds will base on ubuntu:saucy (for now) because it is the best existing, up-to-date, linux containers compliant distribution on the market today. After establishing docker builds we can try to run on other distributions.
As far as I know, neither docker nor LXC support Linux Filesystem quotas. So you wont be able to test the quota system in such a enviroment. My preferred VM technology is OpenVZ, it is lightweight, you can interact with it from the host easiely with exec commands and you can even check files directly as it does not use a image file format to store the vm. I'am testing lxc from time to time as I would love to use a lightweight virtualisation that is part of the default kernel, but until they support filesystem quota it is not usable for servers that host more then one client. But we can use docker as well for the test enviroment, if you prefer that and skip the quota tests, I guess they are not that important. I'am a bit biased torwards openvz as I uses it on all of my servers Thats great Thank you! Ubuntu saucy is fine as base test enviroment. One thing is missing for such automatic setups that I planned for the 3.1 release (next major version). Currently, the installer requests the input from the admin. I would like to add a function that the installer checks for a file install.ini (ini style config file), if he finds that file, he weill not aks the questions that are answered in that ini file. So admins will be able to pre-answer all or just some questions from the installer up to any fully unattended setup.
It is sad to hear quota is not supported inside LXC containers. Nevertheless I will use Docker running existing tests except quota testing. Regarding install.ini I will workaround that for now or implement something if I had a moment Regards, Jan
Ok... So. I have already done a bit of work. All what I have done is covered by tests so ... we have already something to run inside Continous Integration machine. So let's do it However, before that I would like to send my changes to review and discuss few things before my code will hit repository. I'm guessing there is no tool to code review in ispconfig3 community today so I would also want to discuss this point here. 0. Define coding standard 1. Contribution process (describe on wiki) It might be a good idea to agree some common contribution process and setup. Information on the wiki are out-of-date. I could create some new topic (or new wiki) and describe what is on my mind. What is missing for me is: what is the coding standard, how to download source code, where and how create your own repository, how and where send changes to review finally where the build system is and how to check the status of the build. Finally I could describe some idea behind writing tests: naming convention, purpose and so on ... In Review Board wiki pages are part of source code so in the review process people contributing are obligated to fit documentation into code changes. 2. Provide review tool With so straight and clear contirbution process describing life-cycle of each line of code we could setup some review tool. Personally I'm big fan of Review Board - I was a contirbutor few years ago and this is really good peace of software. This is only an idea. If I get permission and access to some machine I can configure and bootstrap instance (and configure with gitlab). 3. Provide CI Finally I could setup CI server. Personally I'm big fan of QuickBuild but it can be anything. If license agreement does not forbid us using QuickBuild I would prefere that particular tool. As far we have 4. Start writing tests After setting up CI development cycle should start be tightly-related with writing tests to each and every part we touch or add. I do not believe we are able to write tests for everything but even writing tests for things we are chaning or improving will give decent code coverage and show us places needs improvements in current code.
Send me the links to the diff views of the changes from git.ispconfig.org by email to dev [at] ispconfig [dot] org or make a merge request on our git server and I can review the request and comment the code there.
