Continuing the discussion from [Contribution] Infra Team:
Should we give a Jenkins 2 a try and set it up? How could we make this lasting? We most likely want some way of automation to bootstrap a new CI slave.
How could we somehow distribute the responsibility of this? We definitely multiple people who could help out fixing the machines.
What else comes to your mind?
cc @stp @elacheche
Hey!
Great idea, I agree that it’s a must to setup a CI server asap, as the devs will start contributing asap too…
I’d like to help/contribute…
How could we somehow distribute the responsibility of this? We definitely multiple people who could help out fixing the machines.
I think that for now, someone should lead the team, he’ll be responsable for pushing things to servers… The rest of the team will be push changes to a git repo with installation instructions (Ansible/Puppet/Chef/Salt???), etc…
We had in the past good experiences with Ansible. I would go for that.
+1 for Ansible too…
@MorrisJobke wanna lead the team? Or someoen else should do that?
If so, I suggest to start with creating a repo on the infre team on Github and creating some issues?! So I (and others) can contribute when ever there is a new issue.
I could lead it. Today I played a bit and set up a Jenkins server. I also tried drone.io as a self-hosted setup and it looks quite good. I will share some ansible stuff once I have it 
As a sidenote I would suggest subdirs of the type: ci.owncloud.org or so. That each directory basically (in infrastructure) shows what it is for.
Great! Let’s rock! 
How can I help on Jenkins?
Drone.io isn’t a saas!
You can start by creating some issues, and I’ll try to help creating the ansible playbooks, I’m not an expert on that, but I created some before, I’ll be happy to practice more 
Do you plan on reusing the existing automated tests ?
Such as smashbox for server/client, perl scripts for client, and so on.
The CI server is critical if you want to merge PR fast and still maintain code reliability.
I’m not sure for core, but afaik for client no automated tests were run on PR (only on daily builds).
Running those tests on PR would be ideal.
I also noticed this and gave it a try today. Looks promising.
Of course. First of all the autotest.sh scripts need to run there. We could then add more.
I would go for drone, because then the configuration is put into the git repo and not inside the CI setup. This would then make it easier to create new task from the developers.
Today we worked on a first setup of a minimal CI instance. The ansible scripts can be found at https://github.com/nextcloud/infrastructure/tree/master/ci
This instance runs at https://drone.weasel.rocks/nextcloud/server (link to the CI setup for the server, because there is no public overview page).
Now the task is to move from our previous setup to a dockerized one. I will soon open a PR in core to run the first tests (autotest.sh sqlite in our server repository) and then we can steadily extend this and play around with all the matrix stuff (multiple PHP versions, DBs, tests, …).
A quick preview:
I used this docker file to generate the php-7-owncloud image:
FROM php:7
RUN apt-get update && apt-get install -y \
libfreetype6-dev \
libjpeg62-turbo-dev \
libpng12-dev \
git \
&& docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \
&& docker-php-ext-install gd zip \
&& docker-php-ext-enable gd zip
RUN curl -O -L https://phar.phpunit.de/phpunit.phar \
&& chmod +x phpunit.phar \
&& mv phpunit.phar /usr/local/bin/phpunit
And following .drone.yml that is placed in the server repository:
build:
image: php-7-owncloud
commands:
- ./occ maintenance:install --database-name oc_autotest --database-user oc_autotest --admin-user admin --admin-pass admin --database sqlite --database-pass=''
- ./autotest.sh sqlite
It currently fails due to a too low memory limit, but it is a nice start. I also opened this on Github as a issue we need to fix as soon as possible in the server repo: https://github.com/nextcloud/server/issues/14
I quickly looked at what drone does and it seems the feature set is very small compared to Jenkins.
The following items in particular raise concerns :
It works just fine. My local tests just run the tests in a PHP docker image. Clearly not an issue
Not needed for the server component here. We could use something different here, but the vast majority of work is done via server CI - so this needs to be working quite robust.
Also not needed.
Works definitely. I already tested this and it shows up nicely in the GitHub details for each PR and just runs the tests on my local instance.
If your goal is to only provide CI integration for the server component, then drone may be a good answer.
But isn’t there value in providing the same CI tool for server and client components ?
Aside from the obvious advantage of having a single pane of glass for every test, there may be some synergies to be had later down the line.
I saw that you quoted the ability to put everything CI in a git repo ; do you mean that what is being done with smashbox (which is hosted in a repo) and Jenkins at ownCloud is not enough ?
The biggest issue was the maintainability of the Jenkins instance, because there some configuration for a job was placed directly in the CI system.
I just enabled the travis jobs. Now also some more code checks are run on travis (only those, because we only have limited resources there)
The drone instance now runs the autotest.sh sqlite test suite