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

[Aaron Conole <aconole@redhat.com>]

Thomas Monjalon <thomas@monjalon.net> writes:

> 02/08/2019 22:59, Aaron Conole:
>> Thomas Monjalon <thomas@monjalon.net> writes:
>> > 31/07/2019 22:54, Michael Santana Francisco:
>> >> On Wed, Jul 31, 2019 at 10:50 AM Aaron Conole <aconole@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.
>
> I don't understand.
> If you set RUN_TESTS and BUILD_DOCS on the same build,
> how is it adding build time?
> I'm just suggesting to make explicit that tests and docs
> are done in the same run.

Sure I'll do that - it's not like I need to mine a new environment
variable from somewhere. :)

>> >> > --- 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.
>
> It looks to be a good reason.
> I'm just sad that we cannot reuse an existing build in another way.
> But I guess the infrastructure cache (ccache or other) will be enough.