> > > > On Mon, Jul 1, 2019 at 6:04 PM Aaron Conole <acon...@redhat.com> wrote: >> >> >> - rwlock_autotest and hash_readwrite_lf_autotest are taking a little more >> >> than 10s, >> >> Occasionally the distributor test times out as well. I've moved them as >> part of a separate patch, that I'll post along with a bigger series to >> enable the unit tests under travis. Michael and I are leaning toward >> introducing a new variable called RUN_TESTS which will do the docs and >> unit testing since those combined would add quite a bit to the execution >> time of each job (and feel free to bike shed the name, since the patches >> aren't final). > > > Seeing how the distributor autotest usually takes less than a second to > complete, this sounds like a bug. > I don't think I caught this so far. So I actually ran into the distributor test timing out. I agree with David in that it is a bug with the test. Looking at the logs that test normally finishes in less than 1/2 a second, so running to 10 seconds and timing out is a big jump in run time. I ran into the issue where it timedout, so I restarted the job and it finished no problem. The test fails every so often for no good reason and the logs[1] dont really say much. I speculate that it is waiting for a resource to become available or in the worse case a deadlock. Seeing that it only fails every so often and it passes when restarted I don't think it's a big deal, nevertheless it's worth investing time figuring out what's wrong
[1] https://api.travis-ci.com/v3/job/212335916/log.txt > > > Yes, we need a variable to control this and select the targets that will do > the tests and/or build the doc. > About the name, RUN_TESTS is ok for me. > > What do you want to make of this variable? > Have it as a simple boolean that enables everything? Or a selector with > strings like unit-tests+doc+perf-tests? > > >> >> >> - librte_table unit test crashes on ipv6 [2], >> >> I guess we're waiting on a patch from Jananee (CC'd)? > > > Yep. > > > -- > David Marchand