-
Notifications
You must be signed in to change notification settings - Fork 426
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a CI tester for running libfwupd with QT threads #2640
Conversation
@aleixpol your tester didn't have a license. Are you OK with it being licensed LGPL2 and included? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to have my code included in LGPL2, thanks!
This only runs on Arch to avoid giving the extra dependencies to all the distro CI builds.
I would think it makes sense to rebase #2638 on this, and whatever the outcome that is done there lands in the tester cpp file. |
The thing is; I don't know how QEventDispatcherGlib actually works. I don't know if the QT5 test case code is valid or not... |
qt5concurrent = dependency('Qt5Concurrent') | ||
glib2 = dependency('glib-2.0') | ||
gio2 = dependency('gio-2.0') | ||
fwupd = dependency('fwupd') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just to clarify; this is the installed fwupd version rather than the "just built" version, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it's explicitly run after install step.
fw->setFuture(QtConcurrent::run([&] { | ||
return fwupd_client_get_devices(client, cancellable, &error); | ||
})); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if this hangs, how do we signify a CI failure? Is github actions going to kill our build after say 30 minutes? I'd much rather have a timer somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a timeout set on the test in meson, so a hang should be killed by the test runner I would expect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But even if that doesn't happen for some reason yes the job will eventually timeout on GitHub too.
This only runs on Arch to avoid giving the extra dependencies to all
the distro CI builds.
Type of pull request: