[openstack-dev] [third-party] One CI for several OpenStack projects
Hi All, I'm working on Third Party CI for Cinder and I've got several issues with Zuul configuration. Third Party CI should run dsvm-tempest-full job to test Cinder driver in my case. It means, that all components should work well, not only Cinder. E.g.: I'm working on Cinder + Ceph integration CI. It requires that RBD-related code in Nova works well. https://bugs.launchpad.net/nova/+bug/1352595 breaks my Cinder CI with Ceph backend last week. So, it looks like I need to setup Cinder Third Party CI with Ceph backend for Cinder and Nova projects. But there are no needs to test Nova with Cinder and Ceph for every Nova commit. I'm looking for something like following: 1) run my Third Party CI for all patch-sets in Cinder 2) run my Third Party CI (Cinder + Ceph backend) for Nova only if it changes nova/virt/libvirt/rbd.py module. Does such approach acceptable for Third Party CI? If yes, does Zuul could handle such kind of triggers? Regards, Ivan Kolodyazhny, Software Engineer, Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [third-party] One CI for several OpenStack projects
On 2014-08-18 20:40:48 +0300 (+0300), Ivan Kolodyazhny wrote: [...] I'm looking for something like following: 1) run my Third Party CI for all patch-sets in Cinder 2) run my Third Party CI (Cinder + Ceph backend) for Nova only if it changes nova/virt/libvirt/rbd.py module. Does such approach acceptable for Third Party CI? If yes, does Zuul could handle such kind of triggers? Zuul has the option to run certain jobs only when it sees specific files mentioned as altered in a Gerrit event. See the files option documented at http://ci.openstack.org/zuul/zuul.html#jobs specifically. This does mean you'd need different job names for those separate cases, but they could effectively perform the same activities (for example if you're also using jenkins-job-builder you could use a single job-template to generate configuration for both and embed a parameter expansion in the template name which is unique per project). -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
