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