David Marchand <david.march...@redhat.com> writes: > On Thu, Feb 20, 2020 at 11:42 AM Thomas Monjalon <tho...@monjalon.net> wrote: >> >> 19/02/2020 22:39, Aaron Conole: >> > David Marchand <david.march...@redhat.com> writes: >> > >> > > Let's prune the jobs list to limit the amount of time spent by the robot >> > > in Travis. >> > > >> > > Since meson enables automatically the relevant components, there is not >> > > much gain in testing with extra_packages vs required_packages only. >> > > >> > > For a given arch/compiler/env combination, compilation is first tested >> > > in all jobs that run tests or build the docs or run the ABI checks. >> > > In the same context, for jobs that accumulates running tests, building >> > > the docs etc..., those steps are independent and can be split to save >> > > some cpu on Travis. >> > > >> > > With this, we go down from 21 to 15 jobs. >> > > >> > > Note: this patch requires a flush of the existing caches in Travis. >> > > >> > > Signed-off-by: David Marchand <david.march...@redhat.com> >> > > --- >> > >> > In general, I think the idea with required vs. extra was to have a build >> > that did the minimum required, and one that did all the packages (to >> > allow a minimum vs. full DPDK). >> > >> > At least, that's from >> > http://mails.dpdk.org/archives/dev/2019-January/124007.html >> >> I think the benefit of a minimum build is to have a quick report, >> and easy to setup. > > Yes, Travis serves as a first gate when submitting patches. > But since Travis is best effort/free, we can't have a full coverage. > > >> > Not sure if that's still something anyone cares about. >> >> Given that Travis knows how to satisfy the dependencies, >> and that we must wait for all jobs to finish, >> I don't see any benefit of a minimal setup. > > This minimal setup also tests that dpdk dependencies are correct. > If a change makes something rely on libX and libX is in the packages > always installed in Travis, the missing dependency would not get > caught. > > But here, this adds too many jobs. > > UNH, Intel and other CIs should step in and fill this kind of gap.
Okay, makes sense to me. Are one of these CI providers offering to cover this? Also, Acked-by: Aaron Conole <acon...@redhat.com> > > -- > David Marchand
