On Thu, Feb 20, 2020 at 3:35 PM Aaron Conole <acon...@redhat.com> wrote: > > 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?
Maybe it is already covered, the best is to ask, so sending to c...@dpdk.org. For the CI guys, which packages are installed on the systems/vms that do compilation tests? Is it possible to have a summary of the different setups? Thanks. -- David Marchand
