[dpdk-dev] [PATCH 2/2] ci: enable unit tests under travis-ci

[Aaron Conole]

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?

Yes.

> 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
looking.

It isn't a big deal to merge them, though if you'd prefer it.