> On Aug 16, 2016, at 3:06 AM, Jean-Paul Calderone <exar...@twistedmatrix.com> > wrote: > > On Mon, Aug 15, 2016 at 7:03 PM, Glyph Lefkowitz <gl...@twistedmatrix.com > <mailto:gl...@twistedmatrix.com>> wrote: > >> On Aug 15, 2016, at 2:11 PM, Jean-Paul Calderone <exar...@twistedmatrix.com >> <mailto:exar...@twistedmatrix.com>> wrote: >> >> On Mon, Aug 15, 2016 at 4:38 PM, Glyph Lefkowitz <gl...@twistedmatrix.com >> <mailto:gl...@twistedmatrix.com>> wrote: >> >>>> There's a lot that we can do to make Travis almost that fast, with >>>> pre-built Docker images and cached dependencies. We haven't done much in >>>> the way of aggressive optimization yet. As recently discussed we're still >>>> doing twice as many builds as we need to just because we've misconfigured >>>> branch / push builds :). >>> >>> Hm... pre-built dockers also takes effort to keep them updated... and >>> then we will have a KVM VM starting inside a docker in which we run >>> the tests... >>> >>> ...and we would not be able to test the inotify part. >> >> Not true: >> >> We can have one non-containerized builder (sudo: true) for testing inotify; >> no need for KVM-in-Docker (also you can't do that without a privileged >> container, so, good thing) >> I'm curious about the details of how such a configuration would work. Since >> there is only one travis configuration per repository (well, per branch, >> technically, don't think that makes a difference here) and the sudo >> configuration is global (isn't it?), I always though either a project had to >> pick sudo or not sudo and you couldn't have a mix of builds with each. > > I had just assumed that it would be per-matrix-entry, and while it looks like > I'm correct, it's much less obvious than I had thought. If you look at the > second example code block under this heading: > > https://docs.travis-ci.com/user/multi-os/#Example-Multi-OS-Build-Matrix > <https://docs.travis-ci.com/user/multi-os/#Example-Multi-OS-Build-Matrix> > > you'll see that one of the matrix/include entries has a 'sudo: required' tag, > which means "non-container-based" please. Presumably you can mix those. > > Ah, neat. I hope that works (and wish I'd noticed that example a couple > months ago). >
I strongly suspect it will, since you can have OS X and Linux builds in the same matrix, and OS X builds are by definition not container based :). > Jean-Paul > > > The docs on "migrating to the container-based infrastructure" do make it > sound like this is impossible though, and this isn't nearly as clear as I'd > like, so it would be nice to actually experiment and see what happens... > >> (Wonky quoting thanks to gmail's wonky web interface, sorry) > > It wasn't too bad - certainly well-worth suffering through for your > contribution :). > > -glyph > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com <mailto:Twisted-Python@twistedmatrix.com> > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > <http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python> > > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com <mailto:Twisted-Python@twistedmatrix.com> > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > <http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python>
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
