Disabling of 'kdav-davitemfetchjob' test in KDav

[Volker Krause]

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?

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191116/0bd87801/attachment.sig>