[CentOS-devel] CI for kubernetes, docker, etcd and other atomic packages

Mon Jun 8 16:23:14 UTC 2015
Jan Chaloupka <jchaloup at redhat.com>

Hi,

at the moment kubernetes, docker, etcd and other atomic packages has no 
CI testing in CentOS. The packages built for CentOS are taken from 
Fedora's repositories. There is already an effort to create CI for 
Fedora builds. Currently kubernetes has its own CI job which can be 
taken as an template for other jobs for docker, etcd, etc. in Fedora. 
The job among other things consists of a builder, i.e. script that can 
be broken down into two parts: installation and testing. The 
installation part takes care of installing, updating and downloading all 
necessary builds. Testing part runs tests. As the script is universal 
and differs only in the installation part, other distributions can reuse 
it. RHEL does that after a simple modification of the installation part. 
The workflow is following: update kubernetes ci job for Fedora, if it 
works, update it for RHEL.

I would like to continue in the same sense for CentOS. Create a job for 
centos's kubernetes. The question is where should it run?  All jobs (for 
Fedora and RHEL) are run in redhat's internal Jenkins. For CentOS it 
would be better to run the job in its own CI environment as this is not 
the only job. Docker, possible etcd and cadvisor can have its own set of 
sets that are suitable. So distributing CI effort among all 
distributions that are involved is natural. Another option is to run all 
centos jobs related to atomic packages in the internal Jenkins.

Why should we bother with running centos's jobs in redhat's environment? 
I have all jobs at one place so I can update them all at once and they 
don't get out of sync. It does not take me much time to create another 
ci job for CentOS once I have created one for Fedora. However, I need a 
trigger that will trigger the job (I have started a discussion on 
setting up fedmsg for CentOS that could provide such a trigger [1]). 
Second, the CI environment is internal so everyone who wants to take a 
look at run jobs must have RH credentials. If CentOS's CI is used the 
responsibility for maintaining all jobs and keeping them in sync is 
completely on CentOS side.

Or something between?
What about I will first test the new or updated job for CentOS in 
internal env and then forward all changes to someone responsible for 
CentOS's CI which would be who? I am not against taking care of this 
part if I get an access/credentials to CentOS to access your CI.

Some jobs in internal RH Ci environment contain private data so I can 
not go public. What can go public is the builder (script) for Fedora. 
However I don't see any benefit sharing the script without the entire 
*.yaml files that create the job. On the other hand if you provide a 
public repository I can contribute to I will update CentOS's jobs as 
changes or new jobs appears. Provided your template for a job.

[1] http://lists.centos.org/pipermail/centos-devel/2015-June/013415.html

Kind Regards
Jan