Disabling of 'kdav-davitemfetchjob' test in KDav

[Ben Cooksley]

On Sat, Nov 16, 2019 at 11:49 PM Volker Krause <vkrause at 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