hooks: update QtNetwork hooks for Qt 6.2 compatibility #6276
Conversation
Simply filtering out "*d.dll" is insufficient as we now have Qt plugins whose names end with "backend" (e.g., "tls/qopensslbackend.dll"). Therefore, upgrade the filtering logic to exclude a DLL whose name ends with "d" only if the corresponding "release" name (i.e., name shortened by one character) also exists.
As of Qt 6.2, we need to collect "tls" plugins as part of QtNetwork for QSslSocket to work. There is another group of plugins that belongs to QtNetwork in Qt 6.2, called "networkinformation". These were introduced in Qt 6.1 as "networkinformationbackends". So collect both variants.
rokm
added
the
needs backport
We currently set QT_DEBUG_PLUGINS=1, but only on ubuntu runner. We should either use it on all OSes, or just enable the extra verbosity when we suspect a problem with plugin loading instead of having it always on.
Run Qt-based tests with offscreen backend instead of default display one. Should both speed up the tests that display the UI, as well as make them more resilient to CI pipeline's display issues (e.g., lack of OpenGL on macOS runners).
bwoodsend
added
the
merge-on-ci-pass
|
Do you want to try just setting the timeout limit higher for that dodgy QtQml test? The variants that are passing are all being flagged up as very slow tests getting close to the 300 seconds mark. |
Ah, that's a good catch, thanks! I had re-run it again to see if it will consistently fail on that particular combination again, so I can try reproducing it locally with the same python version. But if it's a timing issue (slow build and/or slow startup), then we should just raise the timeout limit. |
|
Also this makes me think that that Windows + Python 3.7 + pandas sporadic failure we've been chasing for ages is also just a bit slow. |
For some tests, 5 minutes seems to be cutting it too close... so increase the safety margin.
rokm
added
backported
Qt 6.2 introduced new set of
tlsplugins that need to be collected forQSslSocketto work.