[PATCH weston 2/2] Add .gitlab-ci.yml

[Emil Velikov]

On 7 June 2018 at 08:46, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
> On 6 June 2018 at 16:41, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 6 June 2018 at 15:47, Simon McVittie <smcv at collabora.com> wrote:
>>> On Wed, 06 Jun 2018 at 15:33:13 +0100, Emil Velikov wrote:
>>>> On 5 June 2018 at 23:06, Daniel Stone <daniels at collabora.com> wrote:
>>>> > +  - apt-get -y --no-install-recommends install build-essential automake autoconf libtool pkg-config libexpat1-dev libffi-dev libxml2-dev libpixman-1-dev libpng-dev libjpeg-dev libcolord-dev mesa-common-dev libglu1-mesa-dev libegl1-mesa-dev libgles2-mesa-dev libwayland-dev libxcb1-dev libxcb-composite0-dev libxcb-xfixes0-dev libxcb-xkb-dev libx11-xcb-dev libx11-dev libudev-dev libgbm-dev libxkbcommon-dev libcairo2-dev libpango1.0-dev libgdk-pixbuf2.0-dev libxcursor-dev libmtdev-dev libpam0g-dev libvpx-dev libsystemd-dev libinput-dev libwebp-dev libjpeg-dev libva-dev liblcms2-dev git
>>>>
>>>> I think this can be simplify the explicit list to:
>>>> apt-get -y --no-install-recommends build-dep wayland
>>>
>>> Only if the latest version of wayland has the same build-dependencies
>>> as the (likely much older) version visible in the Sources index
>>> for the container's apt configuration. If the container is
>>> Debian 9 'stretch' (released about a year ago) then apt-get build-dep
>>> will get the build-dependencies of wayland 1.12.0, according to
>>> <https://tracker.debian.org/pkg/wayland>.
>>>
>> Sure, there can be differences. Adding the odd extra piece tends to be
>> shorter and easier (imho) than trying to keep the huge list in sync.
>> Distribution maintainers already that laborious job, why not make use of it.
>
> There are a couple of reasons I typed out the full dependency list.
> One of them is what Simon said, and over time as we get further and
> further away from Stretch, the list of extra stuff we have to add
> grows. Even if we move on to newer Debian, there's also the risk that
> we build things they don't, or some kind of transient dependency drops
> out, so we end up with some breakage. So I prefer the explicit set for
> that reason: it means we can be sure about what we're doing, rather
> than effectively CI'ing the Debian packaging.
>
One could consider build-deps from backports. One could even help the
backports team?
I guess I'm too naive trying to spare the duplication effort?

> Secondly, Stretch was just the easiest starting point: I knew how to
> get it up quickly, in a way where the runtime was also fast (unlike
> with e.g. yum/dnf, where I don't know the necessary runes to speed
> them up). But it's entirely likely we'll want to be testing on other
> distros, or even a very much from-scratch build if we are able to
> reuse the work done on GitLab CI for Mesa here:
>   https://gitlab.com/igalia/graphics/mesa/pipelines/22874845
>
> Either way, having the list of dependencies explictly typed out is
> helpful for whoever's doing the conversion, and it's easy to make sure
> the lists stay in sync if we do have multiple lists.
>
IIRC of all the Linux distros only Arch does not have an equivalent of
build-deps.
Furthermore package names and split varies across distros.

>>>> > +  - make -j4
>>>> > +  - make check
>>>> > +  - make install
>>>> > +  - make distcheck
>>>> I was under the impression that "make -j4 distcheck" is enough
>>>
>>> install and check both imply (depend on) a normal build, so that one is
>>> redundant.
>>>
>>> distcheck runs the tests like check does, but differently-configured,
>>> so for full coverage you might want to do both.
>>>
>>> Similarly, distcheck runs "make install", but into a temporary directory,
>>> not the requested $PREFIX.
>>
>> Right - did not spot that "prefix-*" is also collected as artefacts.
>
> Not just prefix, but also as far as I can see there's no way to
> collect test suite logs from a distcheck run?
If you're want the when logs everything passes, no there isn't a way.
Otherwise, yes - just tweak the regex (example below).

> We've also had
> inexplicable bugs in the past where 'make check' failed but 'make
> distcheck' succeeded (or was it vice-versa?), and given the test
> runtime is still quite short, seemed reasonable enough to explicitly
> test out all of those.
>
Everything aside, this in itself is a fairly valid reason. Currently
the distcheck logs are not fetched though.
The following should help ;-)

    - build-*/weston*/_build/sub/*.log
    - build-*/weston*/_build/sub/logs

>>>> Alternatively it's worth setting MAKEFLAGS="-jX" once so it's used across all.
>>>
>>> Using -j would definitely help for "make distcheck".
>>>
>>> If parallel install works, it would be good to test it so that it stays
>>> that way: quite a lot of projects can build correctly in parallel, but
>>> don't work reliably for "make -jX install".
>>
>> There has been issues in the past and everything ran fine last time
>> I've checked.
>> That's why I'm suggesting adding the toggle ;-)
>>
>> I'm slightly confused if the reply is a) for, b) against or c) simply
>> provides more info.
>> In either way, the background info is always appreciated.
>
> Right, we have certainly had bugs with 'install' in the past.
> Hopefully it's improved now; let's find out, I suppose.
>
Precisely ;-)

As always, I'm full of suggestions - some good, others perhaps too optimistic.
The thread is getting pretty big, so feel free to incorporate the ones
that seem reasonable and forward the rest into the abyss.

HTH
Emil