right now the check_if_older_than_a_week rule does (in pseudo-code):
- get timestamp of current image or 0
- get timestamp of upstream image or 0
- if upstream image is newer than current image
copy upstream image into current
- if we are in a scheduled pipeline, or if there is no current image
(timestamp of 0), rebuild the current image
The ci-templates if-not-exists rule does:
- if there is a current image, exit
- if there is an upstream image, copy it to current and exit
- rebuild
Having the following is equivalent to the current behaviour and
can be used instead of check_if_older_than_a_week:
- if there is an upstream image, copy it to current and exit
- if there is a current image, exit
- rebuild
Because what matters is:
forks should be running the upstream image if available
forks should be running the latest upstream image in the libinput case
forks should be able to rebuild the images if there is no upstream
(change of the image tag)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We better not rebuild the image in regular operations unless there is a
strong need for it.
We can however set up a scheduled pipeline to rebuild the images once
a week or once a month in the upstream repo, and the forks will fetch
those new images when they need.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We should rely on the provided tag, not latest.
Move the clean stage at the end, there is no point in running it at
the beginning.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Now everybody gets to rebuild their own containers if there is a change
(too old or change in the packages). This should allow the MR touching
the package list to succeed.
Removal of the container_check stage, we can just have this in a
before_script.
Removal of the manual creation of the containers, not needed as we better
just increment <DISTRO>_TAG.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We want to have a common repo for the containers templates.
So we can reuse the produced image from this repo and remove our custom
bootstrap image.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This triggers on Fedora 30, even though skip skip the tools options test when
running under valgrind.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not sure how this ever worked correctly: a process terminated by a signal has
the negative signo as return code. This would apply to every debug-events and
debug-gui test because they have to get killed by a signal. This failed
occasionally, presumably a race with the GTK startup/signal handler/whatever.
Fix this by a) sending SIGQUIT because that won't get handled by the tools and
b) prending that if we get a -SIGQUIT exit code, everything is fine.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Pass arguments we don't handle directly through to the unittest module. This
way we can filter tests with -k testname etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Still not great and probably makes any professional designer's eyes bleed, but
at least it's more readable now.
Changes:
- spacing after param name so they don't cuddle up with the description
- color changes and background image removals to drop the doxygen default look
- font size changes to not make things overrun
- font family change to make the function prototypes readable
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that we're emulating everything correctly, let's mark it as proper touch
device.
Two test cases need to be excluded:
- double-down triggers an assert in the test device because this isn't
possible this way with protocol A devices
- the axisrange warning test can't be triggered, mtdev clips those axes
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device mostly behaved like a normal touch device except for
SYN_MT_REPORT. Switch it to behave like a real protocol A device and adjust
the test accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is so we can tell litest to create the device anyway, useful for when all
we have to do in the custom create is allocate some memory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When running the test-suite, don't install our rules for device groups and
model quirks - they're expected to be present already.
Plus, since we copy them from the meson build dir, we don't have
those files available anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All "goto err" resides after fd have been properly initialized.
Fixes "Comparison is always true because fd >= 0." warning by LGTM.
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
The button up debouncing states mirror the button down states with the
addition of the spurious debouncing states. Rename the states to better
show this symmetry.
Multitap sequences (more than 2 taps) had a 180ms timer set only on press,
not on release.
New taps within those 180ms could either trigger multitap+drag or another
multitap (for N+1 taps), resetting the timer on press once again.
If no new tap appears within those 180ms, the sequence was considered
complete.
This behavior differed from regular taps: for the very first tap of a
sequence the timer was set both on touch and on release.
The multitap timing caused misdetection of triple-tap-and-drag sequences as
the timer was hit frequently. Some of those were correctly detected, others
as tripletap only.
Changing the timer to be set on press **and** release gives us a more lenient
timeout. 180ms for tap-and-drag and 180ms for the next tap down after
release. This was also the behavior for the xorg synaptics driver.
Note that quadruple-tap-and-drag didn't suffer from this because the timeout
resulted in double-tap + double-tap-and-drag. Which has the same
user-visible effect.
Now that we're providing the test suite as installed option, distributions
will likely include it as a test package. valgrind is only used for the
meson-specifc test setup. So let's make it optional.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This allows us to run the test suite runner against the installed system
rather than always using the build tree quirks.
The actual option will be removed in a future commit, it is just here for
commit consistency and testing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We want to use this from the tests as well soon, so let's move it to a more
generic location. This also changes the API to be slightly more sensible, a
free() is the same cost (and safer) than passing a static buffer in and hoping
we didn't get the size wrong.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All the bits that test for utility functions to work correctly can be run
separately from the main test suite (which tests devices and libinput in
general). These bits here are the ones that test the code itself and aren't
reliant on anything else.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It's a one-liner, we don't need this as a separate file. Plus, this makes the
test suite runner less dependent on the build directory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If more than 255 tests fail, we're returning an exit code outside of the POSIX
standard. This only takes effect for -j1, where we fork off we only ever have
a failed value of 1 anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
