On Tue, Feb 18, 2020 at 3:55 PM Aaron Conole <acon...@redhat.com> wrote: > > David Marchand <david.march...@redhat.com> writes: > > > On Tue, Feb 18, 2020 at 10:40 AM David Marchand > > <david.march...@redhat.com> wrote: > >> > >> On Mon, Feb 17, 2020 at 7:48 PM Aaron Conole <acon...@redhat.com> wrote: > >> > > >> > David Marchand <david.march...@redhat.com> writes: > >> > > >> > > libabigail 1.2 (at least) reports changes in 'const' property as an ABI > >> > > breakage [1]. > >> > > This was fixed upstream in libabigail 1.4 [2], and a bug has been > >> > > opened > >> > > in launchpad [3]. > >> > > > >> > > But for now, build and use the last version 1.6 so that the ABI checks > >> > > can be kept. > >> > > > >> > > 1: https://travis-ci.com/DPDK/dpdk/jobs/287872118#L2242 > >> > > 2: > >> > > https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commitdiff;h=215b7eb4fe8b986fe1cc87d9d8e7412998038392 > >> > > 3: https://bugs.launchpad.net/ubuntu/+source/libabigail/+bug/1863607 > >> > > > >> > > Signed-off-by: David Marchand <david.march...@redhat.com> > >> > > --- > >> > > >> > Does it make sense to base libabigail required ontop of extra packages? > >> > Otherwise some libraries won't get built / checked, no? > >> > >> The only change I see is the pcap driver being enabled. > >> On the principle, I agree that trying to build all possible > >> libraries/drivers is better when checking the ABI. > >> So I'll keep extra_packages yes. > >> > >> I am currently testing that touching extra_packages (well, testing > >> Thomas patches) results in Travis treating the job as a new one (i.e. > >> with no cache). > > > > Travis bases each job cache on the job description: > > https://docs.travis-ci.com/user/caching/ > > > > I tested Thomas change on extra_packages content, and the job used the > > old cache. > > My idea was to try to put *extra_packages in an env variable, but it > > does not work (my yaml-fu is lacking). > > > > If there is no easy way, I will invalidate the cache manually. > > We don't actually use the EXTRA_PACKAGES variable for anything, so I > guess it's probably okay to change the value and that should invalidate > the cache. Most of the variables, in fact, could be checked for > non-zero value rather than a specific positive value, and then it's easy > to invalidate the cache by just bumping them. It's a thought (and > kindof a hack). Or we can just use the travis CLI tool and delete the > caches (we'll have to do that for the ovsrobot as well, I think). >
What I had in mind was to convert the extra_packages yaml thing into a string to pass into EXTRA_PACKAGES. But I did not manage. About bumping the value, users are likely to be unaware of this step if they submit a patch touching .travis.yml. Deleting the caches from ovsrobot if .travis.yml has been touched seems simpler. On master, I will stick to manual cache invalidation. -- David Marchand -- David Marchand
