On Tue, 2018-05-15 at 13:09 +0100, Daniel P. Berrangé wrote: > On Tue, May 15, 2018 at 02:03:12PM +0200, Andrea Bolognani wrote: > > Why don't we just add Ubuntu 16.04 and Ubuntu 18.04 workers to the > > CentOS CI environment? I'd rather avoid fracturing our CI efforts > > further. > > The CentOS CI runs post-merge, while the travis CI can run pre-merge > on developer's branches. I don't think post-merge vs pre-merge is a big deal, as long as we keep an eye on CentOS CI and react quickly to breakages, which IMHO we're doing reasonably well already. In fact, I believe most libvirt developers don't use Travis CI at all and just fix stuff once CentOS CI highlights it as broken, which is perfectly fine in my book. Additionally, as I mentioned in a previous message, having a local build farm is not too difficult and almost entirely automated these days, so for people looking into smoke-testing their changes that's an overall better route, as it gives full coverage instead of the reduced coverage a Travis CI build provides. Another disadvantage of using a third-party CI provider is that neither Travis CI not GitLab CI allow us to do the kind of integration testing we have going on with CentOS CI, where each change in libvirt triggers builds of bindings and other projects using it. One additional advantage of CentOS CI is that we can have non-Linux and, potentially, non-x86 build guests as well: neither Travis CI nor GitLab CI offer the latter AFAIK, and the former is limited to macOS only on Travis CI. > It is also pushing capacity of the CentOS > CI host to add another 2 VMs to it. I don't think that would tip the scales too much. Builds might take a bit longer, but they are far from being instantaneous already, so in practice a few extra minutes won't change a thing. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
