Re: [dpdk-dev] [PATCH] Introduce travis builds for github repositories

[Aaron Conole <aconole@redhat.com>]

Bruce Richardson <bruce.richardson@intel.com> writes:

> On Wed, Jan 23, 2019 at 05:07:14PM -0500, Michael Santana wrote:
>> GitHub is a service used by developers to store repositories.  GitHub
>> provides service integrations that allow 3rd party services to access
>> developer repositories and perform actions.  One of these services is
>> Travis-CI, a simple continuous integration platform.
>> 
>> This is a simple initial implementation of a travis build for the DPDK
>> project.  It doesn't require any changes from individual developers to
>> enable, but will allow those developers who opt-in to GitHub and the
>> travis service to get automatic builds for every push they make.
>> 
>> Additionally, the travis service will send an email to the test-report
>> list informing anyone interested in the automated build (including a
>> result).
>> 
>> Signed-off-by: Aaron Conole <aconole@redhat.com>
>> Signed-off-by: Michael Santana <msantana@redhat.com>
>> ---
>>  .ci/linux-build.sh                  | 34 +++++++++++++++++++++++++
>>  .ci/linux-setup.sh                  |  3 +++
>>  .travis.yml                         | 39 +++++++++++++++++++++++++++++
>>  MAINTAINERS                         |  6 +++++
>>  doc/guides/contributing/patches.rst |  3 +++
>>  5 files changed, 85 insertions(+)
>>  create mode 100755 .ci/linux-build.sh
>>  create mode 100755 .ci/linux-setup.sh
>>  create mode 100644 .travis.yml
>> 
>> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
>> new file mode 100755
>> index 0000000000..2cfaa05058
>> --- /dev/null
>> +++ b/.ci/linux-build.sh
>> @@ -0,0 +1,34 @@
>> +#!/bin/bash
>> +
>> +# check for whether we're clang or gcc
>> +# setup the right options depending on the environment variables
>> +# run the build
>> +
>> +# Just used for the 'classic' configuration system (ie: make)
>> +set_conf() {
>> +    c="$1/.config"
>> +    shift
>> +
>> +    if grep -q "$1" "$c"; then
>> +        sed -i "s:^$1=.*$:$1=$2:g" $c
>> +    else
>> +        echo $1=$2 >> "$c"
>> +    fi
>> +}
>> +
>> +
>> +if [ "${NINJABUILD}" == "1" ]; then
>> +    meson build
>> +    ninja -C build
>
> Would calling test-meson-builds.sh be a good option here? It runs multiple
> builds rather than a single one.

Maybe it would be better to just fold in the options?  For example, we
already have support for SHARED vs STATIC builds using the standard
config.  Then all we do is change to look like:

  DEF_LIB="static"
  if [ "${SHARED}" == "1" ]; then
      DEF_LIB="shared"
  fi

  meson build --werror -Dexamples=all --default-library=${DEF_LIB}

That will build the static vs shared.  I like it because it keeps the
'matrix' build from travis (see for example,
https://travis-ci.org/orgcandman/dpdk).  Then if some build fails we can
dive into which one failed a little bit easier.  Plus,
test-meson-builds.sh requires all the various compilers be installed to
work right.  I'd rather just flesh out the ci build.

>> +else
>> +    make config T=x86_64-native-linuxapp-${CC}
>> +    if [ "${SHARED}" == "1" ]; then
>> +        set_conf build CONFIG_RTE_BUILD_SHARED_LIB y
>> +    fi
>> +
>> +    if [ "${KERNEL}" == "1" ]; then
>> +        echo Unsupported kernel builds at the moment
>> +    fi
>> +
>> +    make all
>> +fi
>> diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
>> new file mode 100755
>> index 0000000000..6f9849cb94
>> --- /dev/null
>> +++ b/.ci/linux-setup.sh
>> @@ -0,0 +1,3 @@
>> +#!/bin/sh
>> +
>> +python3.5 -m pip install --upgrade meson --user
>> diff --git a/.travis.yml b/.travis.yml
>> new file mode 100644
>> index 0000000000..432d6c9c6c
>> --- /dev/null
>> +++ b/.travis.yml
>> @@ -0,0 +1,39 @@
>> +language: c
>> +compiler:
>> +  - gcc
>> +  - clang
>> +
>> +os:
>> +  - linux
>> +
>> +addons:
>> +  apt:
>> +    sources:
>> +      - deadsnakes #source for python 3.5
>> +      - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> +    packages:
>> +      - libnuma-dev
>> +      - linux-headers-$(uname -r)
>> +      - python3.5
>> +      - python3-pip
>> +      - ninja-build
>> +
>
> Other optional packages we should consider including: libbsd, pcap,
> libcrypto, jansson, zlib.

Makes sense.

> Ideally, I suppose we'd have two setups - one with all the packages, the
> other only with the minimum.

One thing I'd really like to incorporate is a bunch of unit tests that I
can launch...


Thanks for the review, Bruce!