Disabling akonadi test runner infrastructure across all repositories

Ben Cooksley bcooksley at kde.org
Mon Nov 18 08:51:01 GMT 2019


On Mon, Nov 18, 2019 at 9:45 PM Volker Krause <vkrause at 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 <vkrause at 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


More information about the kde-pim mailing list