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

[Bruce Richardson]

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 at redhat.com>
> Signed-off-by: Michael Santana <msantana at 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.

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

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