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

[Daniel Stone]

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.

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.

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

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

Cheers,
Daniel