On Mon, Nov 18, 2019 at 9:45 PM Volker Krause <vkra...@kde.org> wrote: > > On Monday, 18 November 2019 02:55:19 CET Ben Cooksley wrote: > > On Mon, Nov 18, 2019 at 10:18 AM Volker Krause <vkra...@kde.org> wrote: > > > On Sunday, 17 November 2019 21:20:11 CET Albert Astals Cid wrote: > > > > El dissabte, 16 de novembre de 2019, a les 7:02:04 CET, Ben Cooksley va > > > > > > escriure: > > > > > Hi all, > > > > > > > > > > For some time now the Akonadi Test Runner infrastructure has had > > > > > issues on the CI system where it will fail to properly shutdown the > > > > > akonadiserver (and associated subprocesses) that it starts up for > > > > > tests. > > > > > > > > > > This leads to jobs on the CI system becoming indefinitely stuck as > > > > > CTest will wait indefinitely for subprocesses spawned by tests to > > > > > exit. This in turn requires manual cleanup. > > > > > > > > > > Tonight jobs for kdepim-runtime and akonadi itself both required > > > > > manual assistance to complete. Other PIM repositories have in the past > > > > > required similar assistance. > > > > > > > > > > Given that the issue is not limited to a single test or repository, > > > > > i'd therefore like to propose no-oping the entire CMake macro > > > > > responsible for the akonadi test runner framework and disabling all > > > > > tests that make use of it globally across all repositories until this > > > > > issue can be rectified. > > > > > > > > I think it would be really sad to lose all these tests, what's the > > > > timeframe we're speaking here to try to fix them? > > > > > > see replies to the other threads on CI test hangs, I've pushed a possible > > > fix (taken from KIO) to the affected repos. Now waiting to see if that's > > > effective and whether all places were found. > > > > The test hang in the case of Akonadi and associated repositories is > > unrelated to kdeinit5/klauncher/etc issues, as the problem in this > > instance is the akonadiserver instance launched by the test framework > > not being shutdown and cleaned up prior to the test and it's > > associated wrappers exiting. I'm therefore not sure if the same fix > > will apply here... > > Right, that issue might also still be there. The hang that triggered this > discussion in kdepim-runtime however seemed to be due to KIO operations in the > POP3 and EWS tests (similar to what we saw in KDAV and KIO Extras). It's also > possible I misread the logs though :) > > In case the problem persists after all, my original question on how to detect > we are running on the CI becomes relevant again. Is there an environment > variable that would be a sufficiently good indicator for this? I'd really like > to avoid removing useful tests that work perfectly fine locally.
Detecting you are running in the CI system is a bit difficult i'm afraid, as the CI system takes deliberate measures to appear to be a normal system. There are a number of variables set by Jenkins itself you can probably detect though: https://build.kde.org/job/Applications/job/kdepim-runtime/job/kf5-qt5%20SUSEQt5.12/70/consoleText Note that when we transition to Gitlab that these variables would no longer be set as it has it's own set of variables. > > Regards, > Volker Cheers, Ben
