[v6,1/1] ci: Introduce travis builds for github repositories

Message ID 20190304161232.5670-2-msantana@redhat.com
State Superseded, archived
Delegated to: Thomas Monjalon
Headers show
Series
  • Introduce travis support
Related show

Checks

Context Check Description
ci/intel-Performance-Testing success Performance Testing PASS
ci/mellanox-Performance-Testing success Performance Testing PASS
ci/Intel-compilation success Compilation OK

Commit Message

Michael Santana March 4, 2019, 4:12 p.m.
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>
---
v6:
  Removed all classic make builds

 .ci/linux-build.sh                  | 21 +++++++++
 .ci/linux-setup.sh                  |  3 ++
 .travis.yml                         | 73 +++++++++++++++++++++++++++++
 MAINTAINERS                         |  6 +++
 doc/guides/contributing/patches.rst |  4 ++
 5 files changed, 107 insertions(+)
 create mode 100755 .ci/linux-build.sh
 create mode 100755 .ci/linux-setup.sh
 create mode 100644 .travis.yml

Comments

Luca Boccassi March 4, 2019, 6:14 p.m. | #1
On Mon, 2019-03-04 at 11:12 -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>
> ---
> v6:
>   Removed all classic make builds
> 
>  .ci/linux-build.sh                  | 21 +++++++++
>  .ci/linux-setup.sh                  |  3 ++
>  .travis.yml                         | 73
> +++++++++++++++++++++++++++++
>  MAINTAINERS                         |  6 +++
>  doc/guides/contributing/patches.rst |  4 ++
>  5 files changed, 107 insertions(+)
>  create mode 100755 .ci/linux-build.sh
>  create mode 100755 .ci/linux-setup.sh
>  create mode 100644 .travis.yml

Acked-by: Luca Boccassi <bluca@debian.org>
Michael Santana March 14, 2019, 1:21 p.m. | #2
On 3/4/19 1:14 PM, Luca Boccassi wrote:
> On Mon, 2019-03-04 at 11:12 -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>
>> ---
>> v6:
>>    Removed all classic make builds
>>
>>   .ci/linux-build.sh                  | 21 +++++++++
>>   .ci/linux-setup.sh                  |  3 ++
>>   .travis.yml                         | 73
>> +++++++++++++++++++++++++++++
>>   MAINTAINERS                         |  6 +++
>>   doc/guides/contributing/patches.rst |  4 ++
>>   5 files changed, 107 insertions(+)
>>   create mode 100755 .ci/linux-build.sh
>>   create mode 100755 .ci/linux-setup.sh
>>   create mode 100644 .travis.yml
> Acked-by: Luca Boccassi <bluca@debian.org>
>
ping
Thomas Monjalon March 20, 2019, 4:01 p.m. | #3
Hi,

04/03/2019 17:12, Michael Santana:
>  .ci/linux-build.sh                  | 21 +++++++++
>  .ci/linux-setup.sh                  |  3 ++
>  .travis.yml                         | 73 +++++++++++++++++++++++++++++

Please, could you explain somewhere what is the relationship
between these files?
What is specific to Travis?
What is specific to GitHub?

May we add "travis-" as filename prefix of the scripts?
Or rename .ci to .travis?

> +++ b/.ci/linux-build.sh
> @@ -0,0 +1,21 @@
> +#!/bin/bash -xe

If possible, I would prefer a simple /bin/sh.

> +function on_error() {
> +    FILES_TO_PRINT=( "build/meson-logs/testlog.txt" "build/.ninja_log" "build/meson-logs/meson-log.txt")
> +
> +    for pr_file in "${FILES_TO_PRINT[@]}"; do

You can make FILES_TO_PRINT as a simple word list,
and so avoid bashism.

[...]
> +if [ "${AARCH64}" == "1" ]; then

Please explain in the comment where this variable comes from.
I suggest renaming it to ARMV8 as this is what it is translated to:

> +    # convert the arch specifier
> +    OPTS="${OPTS} -DRTE_ARCH_64=1 --cross-file config/arm/arm64_armv8_linuxapp_gcc"

I think -DRTE_ARCH_64=1 is useless.

> +fi
> +
> +OPTS="$OPTS --default-library=$DEF_LIB"
> +meson build --werror -Dexamples=all ${OPTS}
> +ninja -C build
[...]
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,73 @@
> +language: c
> +compiler:
> +  - gcc
> +  - clang
> +
> +dist: xenial

Are we going to update the distribution frequently?
Why not adding more distros?

> +os:
> +  - linux

Is it possible to run on FreeBSD?

> +addons:
> +  apt:
> +    update: true
> +    packages:
> +      - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> +
> +before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
> +
> +sudo: false
> +
> +env:
> +  - DEF_LIB="static"
> +  - DEF_LIB="shared"
> +  - DEF_LIB="static" OPTS="-Denable_kmods=false"
> +  - DEF_LIB="shared" OPTS="-Denable_kmods=false"

How is it different of the matrix below?
Why testing disabling kmods?

> +
> +matrix:
> +  include:
> +  - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
> +    compiler: gcc
> +    addons:
> +      apt:
> +        packages:
> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> +          - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]

Why packages are repeated here again?
(sorry, I don't know Travis and I want to understand)

> +  - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" AARCH64=1
> +    compiler: gcc
> +    addons:
> +      apt:
> +        packages:
> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> +          - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
> +  - env: DEF_LIB="static"
> +    compiler: gcc
> +    addons:
> +      apt:
> +        packages:
> +          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> +  - env: DEF_LIB="shared"
> +    compiler: gcc
> +    addons:
> +      apt:
> +        packages:
> +          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> +  - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
> +    compiler: gcc
> +    addons:
> +      apt:
> +        packages:
> +          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> +  - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
> +    compiler: gcc
> +    addons:
> +      apt:
> +        packages:
> +          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]

It seems clang is not in the matrix. Why?

Thanks for this v6.
I will be available to follow more closely in next days,
so we can merge this feature soon this week.
Michael Santana March 20, 2019, 7:28 p.m. | #4
Thank you for taking at look at this
On 3/20/19 12:01 PM, Thomas Monjalon wrote:
> Hi,
>
> 04/03/2019 17:12, Michael Santana:
>>   .ci/linux-build.sh                  | 21 +++++++++
>>   .ci/linux-setup.sh                  |  3 ++
>>   .travis.yml                         | 73 +++++++++++++++++++++++++++++
> Please, could you explain somewhere what is the relationship
> between these files?
> What is specific to Travis?
> What is specific to GitHub?
>
> May we add "travis-" as filename prefix of the scripts?
> Or rename .ci to .travis?
Only the .travis.yml is specific to travis. The other two files are used 
by travis, but are independent of travis.
This allows us for in the future to change travis as CI and use 
something else instead, or add another CI in addition to travis if we 
wanted to. Other CI's would just run these scripts just like travis does.
With that said, I would not change the names, but if you really think 
they should then it's not a problem
>> +++ b/.ci/linux-build.sh
>> @@ -0,0 +1,21 @@
>> +#!/bin/bash -xe
> If possible, I would prefer a simple /bin/sh.
>
>> +function on_error() {
>> +    FILES_TO_PRINT=( "build/meson-logs/testlog.txt" "build/.ninja_log" "build/meson-logs/meson-log.txt")
>> +
>> +    for pr_file in "${FILES_TO_PRINT[@]}"; do
> You can make FILES_TO_PRINT as a simple word list,
> and so avoid bashism.
Will look into it
>
> [...]
>> +if [ "${AARCH64}" == "1" ]; then
> Please explain in the comment where this variable comes from.
> I suggest renaming it to ARMV8 as this is what it is translated to:
The variable comes from travis. If you look at the matrix in the 
travis.yml you will see lines containing environment variables like 
AARCH64=1.
These lines tell the travis build job to explicitly export these 
variables so that they can be used by the CI scripts like this one.
As for ARMV8 someone had asked specifically to be named AARCH64
>
>> +    # convert the arch specifier
>> +    OPTS="${OPTS} -DRTE_ARCH_64=1 --cross-file config/arm/arm64_armv8_linuxapp_gcc"
> I think -DRTE_ARCH_64=1 is useless.
>
>> +fi
>> +
>> +OPTS="$OPTS --default-library=$DEF_LIB"
>> +meson build --werror -Dexamples=all ${OPTS}
>> +ninja -C build
> [...]
>> --- /dev/null
>> +++ b/.travis.yml
>> @@ -0,0 +1,73 @@
>> +language: c
>> +compiler:
>> +  - gcc
>> +  - clang
>> +
>> +dist: xenial
> Are we going to update the distribution frequently?
> Why not adding more distros?

The only Linux distribution travis supports is Ubuntu, and the latest 
Ubuntu version they support is xenial which is code name for Ubuntu 16.04

>
>> +os:
>> +  - linux
> Is it possible to run on FreeBSD?
Not that I am aware. Travis only supports Ubuntu, Windows, and Mac
>
>> +addons:
>> +  apt:
>> +    update: true
>> +    packages:
>> +      - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> +
>> +before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
>> +
>> +sudo: false
>> +
>> +env:
>> +  - DEF_LIB="static"
>> +  - DEF_LIB="shared"
>> +  - DEF_LIB="static" OPTS="-Denable_kmods=false"
>> +  - DEF_LIB="shared" OPTS="-Denable_kmods=false"
> How is it different of the matrix below?
> Why testing disabling kmods?
This list inherits the packages from the package list above.
The main difference is that this list does not contain extra packages 
such as libbsd-dev, libpcap-dev, etc, where as the matrix below does.
This is so that we have a series of builds with minimal libraries 
installed (Minimal build) and another series of builds with many 
libraries installed (Full build).
We want to mix and match all the possible build scenarios and see if a 
new changes breaks any of the build cases.
The more builds we have with the many different configurations we can 
have the wider the net we can cast to ensure everything is working as it 
should
>
>> +
>> +matrix:
>> +  include:
>> +  - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
>> +    compiler: gcc
>> +    addons:
>> +      apt:
>> +        packages:
>> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> +          - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
> Why packages are repeated here again?
> (sorry, I don't know Travis and I want to understand)
Yeah, we don't want to repeat ourselves either but we have no choice. 
This is due to a limitation in travis.
This matrix does not inherit any packages from the main package list way 
above, which means we have to list them out manually here.
In addition to the required packages we also want to install full builds 
with libraries like libbsd-dev, libpcap-dev, etc.
We could of just put those libraries in the main package list above and 
put all the builds in the env: list because then the libraries would be 
inherited.
The problem with that is that is that travis would not keep minimal 
builds and full builds separate.
We could not have minimal builds because the minimal builds will also 
inherit the additional libraries; Meson will then automatically detect 
those additional libraries and builds with them.
What we would like to have is a way to tell meson which libraries we 
want to use and which we dont, instead of being auto-detected. This 
would help us to get rid of this matrix.

If someone knows a better way to do this we would greatly take in your 
ideas, but so far this is the best we could come up with
>
>> +  - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" AARCH64=1
>> +    compiler: gcc
>> +    addons:
>> +      apt:
>> +        packages:
>> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> +          - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
>> +  - env: DEF_LIB="static"
>> +    compiler: gcc
>> +    addons:
>> +      apt:
>> +        packages:
>> +          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> +  - env: DEF_LIB="shared"
>> +    compiler: gcc
>> +    addons:
>> +      apt:
>> +        packages:
>> +          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> +  - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
>> +    compiler: gcc
>> +    addons:
>> +      apt:
>> +        packages:
>> +          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> +  - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
>> +    compiler: gcc
>> +    addons:
>> +      apt:
>> +        packages:
>> +          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> +          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> It seems clang is not in the matrix. Why?
It looks like my mistake, will look into it
>
> Thanks for this v6.
> I will be available to follow more closely in next days,
> so we can merge this feature soon this week.
>
>
Luca Boccassi March 20, 2019, 9:11 p.m. | #5
On Wed, 2019-03-20 at 15:28 -0400, Michael Santana Francisco wrote:
> > > +matrix:
> > > +  include:
> > > +  - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
> > > +    compiler: gcc
> > > +    addons:
> > > +      apt:
> > > +        packages:
> > > +          - [libnuma-dev, linux-headers-$(uname -r), python3-
> > > setuptools, python3-wheel, python3-pip, ninja-build]
> > > +          - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
> > Why packages are repeated here again?
> > (sorry, I don't know Travis and I want to understand)
> Yeah, we don't want to repeat ourselves either but we have no
> choice. 
> This is due to a limitation in travis.
> This matrix does not inherit any packages from the main package list
> way 
> above, which means we have to list them out manually here.
> In addition to the required packages we also want to install full
> builds 
> with libraries like libbsd-dev, libpcap-dev, etc.
> We could of just put those libraries in the main package list above
> and 
> put all the builds in the env: list because then the libraries would
> be 
> inherited.
> The problem with that is that is that travis would not keep minimal 
> builds and full builds separate.
> We could not have minimal builds because the minimal builds will
> also 
> inherit the additional libraries; Meson will then automatically
> detect 
> those additional libraries and builds with them.
> What we would like to have is a way to tell meson which libraries we 
> want to use and which we dont, instead of being auto-detected. This 
> would help us to get rid of this matrix.
> 
> If someone knows a better way to do this we would greatly take in
> your 
> ideas, but so far this is the best we could come up with

It's yaml so you can write the list to a variable once and reference it
multiple times for brevity, see for example:

https://github.com/zeromq/czmq/blob/master/.travis.yml#L128
Michael Santana March 21, 2019, 3:45 p.m. | #6
On 3/20/19 5:11 PM, Luca Boccassi wrote:
> On Wed, 2019-03-20 at 15:28 -0400, Michael Santana Francisco wrote:
>>>> +matrix:
>>>> +  include:
>>>> +  - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
>>>> +    compiler: gcc
>>>> +    addons:
>>>> +      apt:
>>>> +        packages:
>>>> +          - [libnuma-dev, linux-headers-$(uname -r), python3-
>>>> setuptools, python3-wheel, python3-pip, ninja-build]
>>>> +          - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
>>> Why packages are repeated here again?
>>> (sorry, I don't know Travis and I want to understand)
>> Yeah, we don't want to repeat ourselves either but we have no
>> choice.
>> This is due to a limitation in travis.
>> This matrix does not inherit any packages from the main package list
>> way
>> above, which means we have to list them out manually here.
>> In addition to the required packages we also want to install full
>> builds
>> with libraries like libbsd-dev, libpcap-dev, etc.
>> We could of just put those libraries in the main package list above
>> and
>> put all the builds in the env: list because then the libraries would
>> be
>> inherited.
>> The problem with that is that is that travis would not keep minimal
>> builds and full builds separate.
>> We could not have minimal builds because the minimal builds will
>> also
>> inherit the additional libraries; Meson will then automatically
>> detect
>> those additional libraries and builds with them.
>> What we would like to have is a way to tell meson which libraries we
>> want to use and which we dont, instead of being auto-detected. This
>> would help us to get rid of this matrix.
>>
>> If someone knows a better way to do this we would greatly take in
>> your
>> ideas, but so far this is the best we could come up with
> It's yaml so you can write the list to a variable once and reference it
> multiple times for brevity, see for example:
>
> https://github.com/zeromq/czmq/blob/master/.travis.yml#L128
>
Thank you Luca!
I had previously tested this approach and then it wasn't working the way 
I was hoping it would.
I just finished testing it again and it seems to be working correctly 
this time!
I got it working with the required packages in one list and use a 
variable to reference to that list.
Next I will see about having a list for extra packages, and another for 
ARM packages
Again, thank you! Will work on it

Patch

diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
new file mode 100755
index 000000000..6b65ad31b
--- /dev/null
+++ b/.ci/linux-build.sh
@@ -0,0 +1,21 @@ 
+#!/bin/bash -xe
+
+function on_error() {
+    FILES_TO_PRINT=( "build/meson-logs/testlog.txt" "build/.ninja_log" "build/meson-logs/meson-log.txt")
+
+    for pr_file in "${FILES_TO_PRINT[@]}"; do
+        if [ -e "$pr_file" ]; then
+            cat "$pr_file"
+        fi
+    done
+}
+trap on_error ERR
+
+if [ "${AARCH64}" == "1" ]; then
+    # convert the arch specifier
+    OPTS="${OPTS} -DRTE_ARCH_64=1 --cross-file config/arm/arm64_armv8_linuxapp_gcc"
+fi
+
+OPTS="$OPTS --default-library=$DEF_LIB"
+meson build --werror -Dexamples=all ${OPTS}
+ninja -C build
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
new file mode 100755
index 000000000..63502c90a
--- /dev/null
+++ b/.ci/linux-setup.sh
@@ -0,0 +1,3 @@ 
+ #!/bin/bash
+
+python3 -m pip install --upgrade meson --user
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000000000..b0ab00a9d
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,73 @@ 
+language: c
+compiler:
+  - gcc
+  - clang
+
+dist: xenial
+
+os:
+  - linux
+
+addons:
+  apt:
+    update: true
+    packages:
+      - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+  - DEF_LIB="static"
+  - DEF_LIB="shared"
+  - DEF_LIB="static" OPTS="-Denable_kmods=false"
+  - DEF_LIB="shared" OPTS="-Denable_kmods=false"
+
+matrix:
+  include:
+  - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
+    compiler: gcc
+    addons:
+      apt:
+        packages:
+          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+          - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
+  - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" AARCH64=1
+    compiler: gcc
+    addons:
+      apt:
+        packages:
+          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+          - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
+  - env: DEF_LIB="static"
+    compiler: gcc
+    addons:
+      apt:
+        packages:
+          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+  - env: DEF_LIB="shared"
+    compiler: gcc
+    addons:
+      apt:
+        packages:
+          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+  - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
+    compiler: gcc
+    addons:
+      apt:
+        packages:
+          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+  - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
+    compiler: gcc
+    addons:
+      apt:
+        packages:
+          - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+          - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index 15c53888c..e4b9a8e00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -119,6 +119,12 @@  F: config/rte_config.h
 F: buildtools/gen-pmdinfo-cfile.sh
 F: buildtools/symlink-drivers-solibs.sh
 
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+
 ABI versioning
 M: Neil Horman <nhorman@tuxdriver.com>
 F: doc/guides/rel_notes/deprecation.rst
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 211a5cdc7..22a9039e8 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,10 @@  The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
 Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
 It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
 
+If you are using the GitHub service, you can link your repository to
+the ``travis-ci.org`` build service.  When you push patches to your GitHub
+repository, the travis service will automatically build your changes.
+
 The development process requires some familiarity with the ``git`` version control system.
 Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.