On Sat, Nov 16, 2019 at 11:49 PM Volker Krause <vkra...@kde.org> wrote: > > On Saturday, 16 November 2019 11:26:39 CET Volker Krause wrote: > > On Saturday, 16 November 2019 07:04:57 CET Ben Cooksley wrote: > > > Hi everyone, > > > > > > Currently we have an issue where the test 'kdav-davitemfetchjob' within > > > kdav causes kdeinit5 to be relaunched, as can be seen in the CI > > > run log below. > > > > > > https://build.kde.org/job/Applications/job/kdav/job/kf5-qt5%20SUSEQt5.12/3 > > > 8/ console > > > > > > This is behaviour which is not permitted within the CI system, as the > > > newly spawned 'kdeinit5' processes are treated as being launched by > > > that test by CTest, meaning it will wait for eternity for them to exit > > > (which as resident daemon processes, they will not do without manual > > > intervention). > > > > > > This in turn blocks the job from completing, and blocks CI resources > > > in the process. > > > > > > I'd therefore like to propose disabling this test across all platforms > > > as it's behaviour is incompatible with the CI system. > > > > uh, I wasn't even aware of that problem for KDAV... > > turns out there's a reason for this: the problem only started to occur after a > build run on Nov 15 triggered without source code changes (yesterday), before > this the entire tests for kdav finished in less than a minute. > > > The test doesn't do anything special regarding kdeinit, it does run a KIO > > HTTP job against a local fake server though, which I guess triggers this. > > > > I've added the same workaround that KIO seems to use: https://cgit.kde.org/ > > kdav.git/commit/?id=c6fb178a38028281fea9bae48ca3c6a9e6d04059 > > That alone wasn't enough, it needs: > > qputenv("KDE_FORK_SLAVES", "yes"); > qputenv("KIO_DISABLE_CACHE_CLEANER", "yes"); > > With that kdav works fine again. > > > If that doesn't help, I'm wondering if there's a way to disable such > > problematic tests only on the CI (also with regard to the Akonadi test > > issue), as those tests work fine locally and are useful there. Is there > > maybe a characteristic environment variable that we can use to easily check > > for this in CMake? > > Probably not needed after all, the two other reported issue in akonadi and > kdepim-runtime are the same problem, HTTP KIO operations that have been around > since a long time now starting to get stuck. I'll look into applying the same > fix there. > > As this all started at the same time, I guess there was some change to either > KIO or the CI environment yesterday that started to trigger this?
The CI images themselves were last rebuilt 4 weeks ago, so they're innocent in this regard. Likewise, the CI Tooling itself hasn't changed in any meaningful way here either. I'd say this is a regression within KIO/Kdeinit. > > Regards, > Volker Cheers, Ben
