We've had this for roughly 10y now and it's value is dubious. Most of
xorg no longer requires, mesa accepts but doesn't require it, most of GNOME
doesn't accept it and neither does systemd.
Let's drop the requirement.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libevdev/libevdev/-/merge_requests/123>
Commit originally by Simon Ser in wayland/wayland-protocols!305.
Currently our CI setup has a downside: for each push on a merge
request, two pipelines are triggered. The first is triggered in
the context of the forked repository, and the second is triggered
in the context of the MR in the parent repository.
Replace the workflow rules with the ones in the official docs [1],
so that a branch pipeline isn't triggered when a MR exists for that
branch.
[1]: https://docs.gitlab.com/ee/ci/yaml/workflow.html#switch-between-branch-pipelines-and-merge-request-pipelines
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is copied from libinput's CI but as one large change rather than
cherry-picking the process on how to get here. meson-build.sh is synched
with libinput's version - it is a more generic version anyway.
With this change we no longer require separate images for the qemu runs,
our default image is qemu-capable and can be run in qemu via
boot2container (b2c).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only use the LIBEVDEV_SKIP_ROOT_TESTS env var in autotools where we need
it, in meson we can use meson to control which tests we (don't) want to
run.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unlike autotools distcheck which ensures we didn't forget to add
anything to the makefiles, ninja dist just zips up the git repo.
It does run the tests though but without suite selection which is a
problem for us here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use the new needs-uinput suite specifier for the meson build job, and
use --no-tests for ninja dist in the autotools build job.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In the no-check:meson job, the ninja arg was "dist" so the test would be
run as part of that anyway (and skipped, since we didn't have check).
In the no-doxygen-check:meson job, the ninja arg was zero so the test
would be skipped but since we don't have check we might as well just
run it as empty test suite.
And the same applies to the scan-build job, running the test shouldn't
hurt here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Required by the debian sid containers, otherwise we fail because of a
missing /etc/apt/sources.list file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No big point building for Centos 7 anywmore, and Centos 8 is now Centos
Stream only which needs fixing in the CI templates first.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Generate the snippet for whichever is the last version in the list for the
want_qemu tag.
And move the want_qemu tag up so it's more obvious in the config file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This requires latest CI templates for the mkosi changes. Since the start_vm.sh
script is now gone, switch to using vmctl instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We still require Fedora for the various jobs with custom autotools/meson
configurations. But we might as well make it dependent on the config file
entries only than hardcoding it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This gives the developer enough time to file an MR after pushing a branch.
Having this run in the first stage means we get false positives because no MR
has been filed yet when the job is run.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ci-templates now has a new tool ci-fairy that replaces our jinja generation
script with something (eventually) unified across project repositories. Let's
move the files to the expected locations .gitlab-ci/config.yml and
.gitlab-ci/ci.template.
ci-fairy also has a wrapper to delete images, let's start using that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
