From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id EFC01A10DA for ; Fri, 2 Aug 2019 15:34:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E3FBA1C296; Fri, 2 Aug 2019 15:34:49 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 6DEA61C295 for ; Fri, 2 Aug 2019 15:34:48 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9EE48308FC22; Fri, 2 Aug 2019 13:34:47 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.67]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D2A4819C68; Fri, 2 Aug 2019 13:34:46 +0000 (UTC) From: Aaron Conole To: Michael Santana Francisco Cc: dev , David Marchand , Bruce Richardson , Ferruh Yigit , Luca Boccassi References: <20190731145030.19956-1-aconole@redhat.com> <20190731145030.19956-3-aconole@redhat.com> Date: Fri, 02 Aug 2019 09:34:46 -0400 In-Reply-To: (Michael Santana Francisco's message of "Wed, 31 Jul 2019 16:54:46 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Fri, 02 Aug 2019 13:34:47 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 2/2] ci: enable unit tests under travis-ci X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Michael Santana Francisco writes: > On Wed, Jul 31, 2019 at 10:50 AM Aaron Conole wrote: >> >> When building under Travis (or another linux CI service), enable running the >> fast-tests for selected builds. Only the shared builds are enabled at this >> point, since they are the ones passing. Builds that are statically linked >> still show some issues in some of the eal_flags tests. Additionally, >> the command to invoke fast tests includes a timeout multiplier, since >> some CI environments don't have enough resources to complete the tests in >> the default 10s timeout period. >> >> Signed-off-by: Aaron Conole >> --- >> .ci/linux-build.sh | 8 ++++++++ >> .ci/linux-setup.sh | 8 +++++++- >> .travis.yml | 9 ++++++++- >> 3 files changed, 23 insertions(+), 2 deletions(-) >> >> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh >> index d5783c1a4..75f740648 100755 >> --- a/.ci/linux-build.sh >> +++ b/.ci/linux-build.sh >> @@ -22,3 +22,11 @@ fi >> OPTS="$OPTS --default-library=$DEF_LIB" >> meson build --werror -Dexamples=all $OPTS >> ninja -C build >> + >> +if [ "$RUN_TESTS" = "1" ]; then >> + # On the test build, also build the documentation, since it's expensive >> + # and we shouldn't need to build so much of it. >> + ninja -C build doc >> + >> + sudo meson test -C build --suite fast-tests -t 3 >> +fi >> diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh >> index acdf9f370..a40e62eaa 100755 >> --- a/.ci/linux-setup.sh >> +++ b/.ci/linux-setup.sh >> @@ -1,3 +1,9 @@ >> #!/bin/sh >> >> -python3 -m pip install --upgrade meson --user >> +# need to install as 'root' since some of the unit tests won't run without it >> +sudo python3 -m pip install --upgrade meson >> + >> +# setup hugepages >> +cat /proc/meminfo >> +sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages' >> +cat /proc/meminfo > Can we drop cat /proc/meminfo? >> diff --git a/.travis.yml b/.travis.yml >> index 7b167fa64..c0c27bb7f 100644 >> --- a/.travis.yml >> +++ b/.travis.yml >> @@ -30,6 +30,7 @@ env: >> - DEF_LIB="shared" >> - DEF_LIB="static" OPTS="-Denable_kmods=false" >> - DEF_LIB="shared" OPTS="-Denable_kmods=false" >> + - DEF_LIB="shared" RUN_TESTS=1 > I don't agree with this. This is redundant. Why not put RUN_TESTS=1 on > an already exiting builds instead of adding two new builds like you > are doing here? > A build without the tests takes ~7 minutes, with the tests it > increases to ~9 minutes. These two new builds add ~18 minutes of build > time to the entire travis build time. We could use this ~18 minutes > instead to run the tests on 6 to 9 already existing builds since they > take 2 to 3 extra minutes on each one. Hi Michael, The ovsrobot was off for a bit due to an internal issue. Now that it's back, a new build was generated. Please have a look. The time delta is about 8-12 minutes (because builds are in parallel) for a complete run (that's with all of the various jobs which make up a build). Do you think it's unreasonable? -Aaron