[dpdk-dev] [PATCH 2/2] ci: enable unit tests under travis-ci
aconole at redhat.com
Fri Aug 2 22:59:26 CEST 2019
Thomas Monjalon <thomas at monjalon.net> writes:
> 31/07/2019 22:54, Michael Santana Francisco:
>> On Wed, Jul 31, 2019 at 10:50 AM Aaron Conole <aconole at redhat.com> wrote:
>> > --- 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
> I am not sure to understand the comment.
> Do you mean you build the documentation only once,
> which is when running tests?
> Why it is not a new option similar as RUN_TESTS?
I mentioned it at:
http://mails.dpdk.org/archives/dev/2019-July/136635.html also. Because
it adds build time.
>> > --- 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?
> I agree it is a strange logic.
> Why not use an existing build to run the tests?
The biggest reason is when it fails, it is difficult to know why "at a
glance." When it does fail due to unit tests, it sometimes takes a
long time to load the logs - so just knowing that the failure is likely
in the unit tests area vs. build is helpful to understand where to start
It isn't a big deal to merge them, though if you'd prefer it.
More information about the dev