[Mesa-dev] [PATCH] travis: Initial import of travis instructions.

Tue Nov 24 23:20:37 PST 2015

On 24/11/15 21:38, Rob Clark wrote:
> On Tue, Nov 24, 2015 at 4:10 PM, Eric Anholt <eric at anholt.net> wrote:
>> Rob Clark <robdclark at gmail.com> writes:
>>
>>> On Tue, Nov 24, 2015 at 2:10 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> On Tue, Nov 24, 2015 at 2:04 PM, Eric Anholt <eric at anholt.net> wrote:
>>>>> This just builds/installs our dependencies, and runs "make check".  I'm
>>>>> interested in integrating more tests into it, but this seems like a pretty
>>>>> easy first start.
>>>>>
>>>>> If your personal branches of Mesa are on github, you can enable it on your
>>>>> account and the repository (see
>>>>> https://docs.travis-ci.com/user/for-beginners), then any pushes you do
>>>>> will get their HEAD commit tested, and any pull requests to your tree will
>>>>> get their merge commits tested.
>>>>> ---
>>>>>
>>>>> I'd really like to have *some* sort of publicly available CI for
>>>>> people hacking on Mesa.  We've all seen how many times make check has
>>>>> been broken, so this was an easy start.  Travis doesn't seem optimal,
>>>>> since it doesn't test each commit, but I think it's better than
>>>>> nothing, and the cost is this little file and bumping the versions of
>>>>> dependencies to download when we update configure.ac requirements.
>>>>>
>>>>>   .travis.yml | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>   1 file changed, 92 insertions(+)
>>>>>   create mode 100644 .travis.yml
>>>>>
>>>>> diff --git a/.travis.yml b/.travis.yml
>>>>> new file mode 100644
>>>>> index 0000000..31cd5c2
>>>>> --- /dev/null
>>>>> +++ b/.travis.yml
>>>>> @@ -0,0 +1,92 @@
>>>>> +language: c
>>>>> +
>>>>> +sudo: false
>>>>> +
>>>>> +cache:
>>>>> +  directories:
>>>>> +    - $HOME/.ccache
>>>>> +
>>>>> +addons:
>>>>> +  apt:
>>>>> +    packages:
>>>>> +      - libdrm-dev
>>>>> +      - libudev-dev
>>>>> +      - x11proto-xf86vidmode-dev
>>>>> +      - libexpat1-dev
>>>>> +      - libxcb-dri2-0-dev
>>>>> +      - libx11-xcb-dev
>>>>> +      - llvm-3.4-dev
>>>>> +
>>>>> +env:
>>>>> +  global:
>>>>> +    - XORG_RELEASES=http://xorg.freedesktop.org/releases/individual
>>>>> +    - XCB_RELEASES=http://xcb.freedesktop.org/dist
>>>>> +    - XORGMACROS_VERSION=util-macros-1.19.0
>>>>> +    - GLPROTO_VERSION=glproto-1.4.17
>>>>> +    - DRI2PROTO_VERSION=dri2proto-2.8
>>>>> +    - DRI3PROTO_VERSION=dri3proto-1.0
>>>>> +    - PRESENTPROTO_VERSION=presentproto-1.0
>>>>> +    - LIBPCIACCESS_VERSION=libpciaccess-0.13.4
>>>>> +    - LIBDRM_VERSION=libdrm-2.4.65
>>>>> +    - XCBPROTO_VERSION=xcb-proto-1.11
>>>>> +    - LIBXCB_VERSION=libxcb-1.11
>>>>> +    - LIBXSHMFENCE_VERSION=libxshmfence-1.2
>>>>> +    - PKG_CONFIG_PATH=$HOME/prefix/lib/pkgconfig
>>>>> +
>>>>> +install:
>>>>> +  - export PATH="/usr/lib/ccache:$PATH"
>>>>> +  - pip install --user mako
>>>>> +
>>>>> +  # Install dependencies where we require specific versions (or where
>>>>> +  # disallowed by Travis CI's package whitelisting).
>>>>> +
>>>>> +  - wget $XORG_RELEASES/util/$XORGMACROS_VERSION.tar.bz2
>>>>> +  - tar -jxvf $XORGMACROS_VERSION.tar.bz2
>>>>> +  - (cd $XORGMACROS_VERSION && ./configure --prefix=$HOME/prefix && make install)
>>>>> +
>>>>> +  - wget $XORG_RELEASES/proto/$GLPROTO_VERSION.tar.bz2
>>>>> +  - tar -jxvf $GLPROTO_VERSION.tar.bz2
>>>>> +  - (cd $GLPROTO_VERSION && ./configure --prefix=$HOME/prefix && make install)
>>>>> +
>>>>> +  - wget $XORG_RELEASES/proto/$DRI2PROTO_VERSION.tar.bz2
>>>>> +  - tar -jxvf $DRI2PROTO_VERSION.tar.bz2
>>>>> +  - (cd $DRI2PROTO_VERSION && ./configure --prefix=$HOME/prefix && make install)
>>>>> +
>>>>> +  - wget $XORG_RELEASES/proto/$DRI3PROTO_VERSION.tar.bz2
>>>>> +  - tar -jxvf $DRI3PROTO_VERSION.tar.bz2
>>>>> +  - (cd $DRI3PROTO_VERSION && ./configure --prefix=$HOME/prefix && make install)
>>>>> +
>>>>> +  - wget $XORG_RELEASES/proto/$PRESENTPROTO_VERSION.tar.bz2
>>>>> +  - tar -jxvf $PRESENTPROTO_VERSION.tar.bz2
>>>>> +  - (cd $PRESENTPROTO_VERSION && ./configure --prefix=$HOME/prefix && make install)
>>>>> +
>>>>> +  - wget $XCB_RELEASES/$XCBPROTO_VERSION.tar.bz2
>>>>> +  - tar -jxvf $XCBPROTO_VERSION.tar.bz2
>>>>> +  - (cd $XCBPROTO_VERSION && ./configure --prefix=$HOME/prefix && make install)
>>>>> +
>>>>> +  - wget $XCB_RELEASES/$LIBXCB_VERSION.tar.bz2
>>>>> +  - tar -jxvf $LIBXCB_VERSION.tar.bz2
>>>>> +  - (cd $LIBXCB_VERSION && ./configure --prefix=$HOME/prefix && make install)
>>>>> +
>>>>> +  - wget $XORG_RELEASES/lib/$LIBPCIACCESS_VERSION.tar.bz2
>>>>> +  - tar -jxvf $LIBPCIACCESS_VERSION.tar.bz2
>>>>> +  - (cd $LIBPCIACCESS_VERSION && ./configure --prefix=$HOME/prefix && make install)
>>>>> +
>>>>> +  - wget http://dri.freedesktop.org/libdrm/$LIBDRM_VERSION.tar.bz2
>>>>> +  - tar -jxvf $LIBDRM_VERSION.tar.bz2
>>>>> +  - (cd $LIBDRM_VERSION && ./configure --prefix=$HOME/prefix && make install)
>>>>> +
>>>>> +  - wget $XORG_RELEASES/lib/$LIBXSHMFENCE_VERSION.tar.bz2
>>>>> +  - tar -jxvf $LIBXSHMFENCE_VERSION.tar.bz2
>>>>> +  - (cd $LIBXSHMFENCE_VERSION && ./configure --prefix=$HOME/prefix && make install)
>>>>> +
>>>>> +# Disabled LLVM (and therefore r300 and r600) because the build fails
>>>>> +# with "undefined reference to `clock_gettime'" and "undefined
>>>>> +# reference to `setupterm'" in llvmpipe.
>>>>> +script:
>>>>> +  - ./autogen.sh --enable-debug
>>>>> +    --disable-gallium-llvm
>>>>> +    --with-egl-platforms=x11,drm
>>>>> +    --with-dri-drivers=i915,i965,radeon,r200,swrast,nouveau
>>>>> +    --with-gallium-drivers=svga,swrast,vc4,virgl
>>>>
>>>> Any reason not to add freedreno and nouveau in here?
>>>>
>>>> Too bad these packages don't all have "latest" symlinks...
>>>
>>> hmm, I was going to say that tinderbox can figure out how to just
>>> build latest (plus we at one point had builders for several different
>>> arch's for xserver and mesa, etc..)
>>>
>>> but then I noticed that http://tinderbox.x.org/ is in kind of dire shape.. :-(
>>
>> I've run tinderbox servers before.  It's a bunch of work, and then
>> nobody looks at it anyway, including me.  It also only tests your pushes
>> once they've hit master, which to me misses the whole point.
>>
>> The github integration means that people doing things on github see CI
>> state in their interfaces (well, in pull requests.  If you just want
>> current state, you have to go to the travis-ci.org dashboard).  It also
>> sends me emails when my branch pushes fail.
>
> yeah, I've run tinderbox builder too, so I know the issues..
>
> All the same, it's probably still a good idea to resurrect tinderbox
> to get build coverage on different archs..  the clever thing would be
> if we could also work in piglit runs as well (ie. at least for
> whatever gpu(s)) the various builders have..
>
> It may just end up being best to have both, at least as long as this
> is low effort to keep going, it doesn't hurt.  And the convenience for
> personal git trees is a win.
>
> BR,
> -R

I don't have any experience with buildbot.

But I also run my own Jenkins CI instance for Mesa/Piglit/Apitrace/etc 
plus Travis/Appveyor for Apitrace, and I also feel there's advantages 
for both.

The good thing of Jenkins is that I don't need to build everything from 
scracth on every machine -- I have some jobs building the drivers/test, 
and then lots of slaves testing them in parallel.

The good thing of cloud services like Travis/Appveyor is that they can 
easily test every branch and pull request as noted.  Plus they are 
public, so you don't worry about securing your own CI deployment.

BTW, I setup Mesa with Appveyor (like Travis for Windows)

   https://ci.appveyor.com/project/jrfonseca/mesa

I'll try to get that going and commited too.

The nice thing about Appveyor is that it can clone the git from 
anywhere, not just GitHub.

Would it be OK to have email notifications to mesa-commits?

Jose