[libvirt PATCH 2/3] travis: Reduce test matrix

Andrea Bolognani abologna at redhat.com
Wed Apr 15 16:05:04 UTC 2020

On Wed, 2020-04-15 at 13:52 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 14, 2020 at 12:42:26PM +0200, Andrea Bolognani wrote:
> > Considering that almost nobody in the libvirt community is actually
> > focused on macOS support, trying to chase after two SDKs instead of
> > a single one doesn't necessarily sound like a good idea to me,
> > especially when the older one doesn't target the current version of
> > macOS.
> > 
> > It's already pretty bad that we're stuck on 10.14, as opposed to
> > 10.15 which is the version we actually target according to our
> > platform support policy, because Travis CI always takes forever to
> > prepare new images.
> I don't see that as a big deal really. The older platforms are
> generally more interesting, as they're more likely to be lacking
> features we depend on. Being able to validate multiple XCode
> versions is interesting as they're different compiler toolchain
> versions and so likely to spit out different warnings.

I think coverage of older platforms is useful if we still target
them, and a nuisance otherwise.

As for older toolchains, we obviously need that for platforms where
the toolchain can't be upgraded separately from the OS, but that's
not the case on macOS, and given that Xcode updates are free of
charge and introduce significant new features, I doubt many
developers stick with older releases for longer than they need to.

> > I was looking into Cirrus CI the other day and they support macOS
> > too, and they even already have a 10.15 image. I didn't dig deeper,
> > but maybe if we're stuck using an external service for macOS builds
> > it should be Cirrus CI instead of Travis CI.
> Cirrus only seems to offer latest version of XCode, so that's not
> especially appealing IMHO.

That version of Xcode is running on the latest macOS version, the
one we actually target. That's a big plus in my book.

Andrea Bolognani / Red Hat / Virtualization

More information about the libvir-list mailing list