> On 24 Jun 2022, at 14:48, Mårten Nordheim <marten.nordh...@qt.io> wrote: > > Hello, > > Some time yesterday a certificate used in the network tests expired. > The certificate has been replaced in CI now, but the tests need to be updated. > The patch[0] for that is done, it just needs to merge (and be cherry-picked > to whatever > branch you're interested in). Until then your merges and pre-checks will fail. > > Note that even after the patch has merged and prechecks will need to be > rebased > on top of this change to pass CI. > > Once again, this only affects qtbase, apologies for the inconvenience! > > > Mårten > > [0] https://codereview.qt-project.org/c/qt/qtbase/+/418583
Thanks for looking after that, Mårten! Perhaps this is a good time to discuss whether we should move Qt Network into its own repository. This would make qtbase integrations less exposed to network failure, which - even without certificates expiring - are a fact of life. And qtbase integrations already suffer from plenty of flakiness. And that an operational issue might require patches to merge and to get cherry picked, which might take several attempts, each taking several hours, just amplifies that problem further. Conceptually, we have made that kind of change before (when taking Qt Positioning out of the qtlocation repo). But there are some challenges. One challenge is that several of our Qt Core tests are using networking features (tests outside of tests/auto/network that include network-settings.h: tst_qdir, tst_qdiriterator, tst_qfile, tst_qfileinfo, tst_qiodevice, tst_qtextstream, tst_qfiledialog2). Without having looked into the details, I’d assume that we might not need an actual server to test many of those codepaths (or that those tests can be moved into a qtnetwork repo, ie. QTextStream::stillOpenWhenAtEnd doesn’t seem to test QTextStream, which never closes a QIODevice). Volker _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
