 Hi, I'm Morris and recently I worked on CI at NexCloud, CI means continuous integration, which is just executing all our tests we have here in our code base automatically on every pull request and only after tests all pass, then it's allowed to merge a pull request. And that's how usually a continuous integration looks like, you see for example the pull request number on the top and then the lock output of the test run and here you see the software drone because I chose it because it was just too much work to set up Jenkins and I looked for an alternative that's easier to configure and especially to have the configuration not on the server but actually in the Git repository where all the developers work and add new tests and automatic tests that can be run and this is specified in a dot drone dot channel file and that looks like this here, this is one test run and the nice thing about this is that you don't rely on installed software on the server, on your CI server but you simply specify one Docker image that is used and then all the tests are executed inside this Docker image. It makes it at least more reproducible on different hosts so you can also run it locally and on different servers and don't need to care about oh I need to install PHP and PHP 7 and PHP 5.5 and all PHP unit and all external dependencies but you simply ship them all in one Docker container and use that one that made it a lot easier to also scale out work across here. In this case it executes the app code checker and runs our OCC command which does it and if the exit code is non-zero then something bad happened and you better fix the app. Recently we had in place for yes since June to two weeks ago we had drone 04 live which was quite limiting because there were only sequential execution of all tests allowed and no parallel execution which limited us in running different and many automated tests and recently we switched to the new version of our 05 it looks a bit more like Travis and what really nice is that it allows for parallel execution of all steps so now we will focus on adding even more tests and executing more tests automatically that's what we added really really lately especially all the all the litmus tests and called off a tester and called off tester before it was simply executed manually but now we added it to the to the automated list and yeah it's it's growing every week and yeah what's what's up in the future on the new future is that we add even more tests for especially files external where we test for example sambar mounts or object store mounts and try to to also add tests for the primary storages so that all tests are not only run on local local disk but also on for example the object object store we support which is currently only run manually and what uh what is the next biggest goal is to have this smashbox test up and running because that are the actually okay we have a client fired up running complete synchronization cycle and then see if all all went well this country just executed manually really regularly but that's yeah free some time on this side and we can want this automatically what i would like to do a yeah recommend is to try to move all apps from trevis and because trevis has a read hard limitation of only allowing two parallel test executions for a whole organization that means for us we have a lot of apps for example the mail app maintainers always complain about it because mail up and i guess the android client if they if they work in parallel they always run in some yeah i need to wait five hours until the trevis executes my tests it's quite annoying and that would allow us to just throw more hardware on our side and fix this this time constraint yeah that's it from my side if you want uh to know more about this and how to set it up just come over talk to me or mention me on github i will help you