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

[Thomas Monjalon <thomas@monjalon.net>]

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.

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