Notice of withdrawal of CI services: KDevelop and KDE Connect

[Ben Cooksley]

On Fri, Jun 18, 2021 at 7:33 AM Milian Wolff <mail at milianw.de> wrote:

> On Donnerstag, 17. Juni 2021 11:25:15 CEST Ben Cooksley wrote:
> > On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff <mail at milianw.de> wrote:
> > > On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote:
> > > > Hi all,
> > > >
> > > >
> > > > The following is notice that I intend to withdraw CI services from
> the
> > > > following two KDE projects due to faults in their code or build
> system
> > > > which are having a significant adverse impact on the CI system and
> > > > negatively impacting on other projects:
> > > >
> > > > - KDevelop
> > > > - KDE Connect
> > > >
> > > > This withdrawal will be applied to all platforms.
> > > >
> > > > In the case of KDevelop, it has a series of unit tests which on
> FreeBSD
> > > > cause gdb to hang and consume an entire CPU core indefinitely. This
> > > > slows
> > > > down builds for all other projects using that CI server, and also
> > >
> > > prevents
> > >
> > > > KWin tests from proceeding - completely blocking it's jobs. This
> fault
> > > > is
> > > > in the debuggee_slow family of tests.
> > >
> > > Hey Ben,
> >
> > Hi Milian,
> >
> > > first time I hear of this issue. I simply don't have the capacity to
> track
> > > kdevelop CI mails, so if anything really bad happens, I would really
> > > appreciate if anyone who notices that sents a mail to the kdevelop
> mailing
> > > list so we can act on it. I still use kdevelop daily, but don't put any
> > > other
> > > work in it currently due to lack of time...
> >
> > The issue in question was noted on #kdevelop (prior to the whole Freenode
> > meltdown) on a few occasions.
>
> Even before that meltdown, I only looked at this when I was directly
> pinged.
> Please prefer to use the mailing lists to get our attention.
>

Certainly.


>
> > > That said: can we just disable it on the FreeBSD platform, if that's
> the
> > > only
> > > one that exhibits this failure? Alternatively I'm obviously fine with
> > > skipping
> > > that test on that platform, can you give me a link to a failure please
> so
> > > I
> > > can see which tests exactly are affected? Then I'll add the QSKIP +
> > > platform
> > > ifdef checks to skip it on freebsd.
> >
> > I'm afraid I only have records of the hung test processes (and the gdb
> > processes above them using an entire CPU core indefinitely each).
> >
> > jenkins    60635   0.0  0.0   12120   2256  0  TXs+ 02:44         0:00.00
> > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5
> >
> FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees
> > low (debuggee_debugeeslo)
> > jenkins    74167   0.0  0.0   12120   2260  1  TXs+ 02:55         0:00.00
> > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5
> >
> FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees
> > low (debuggee_debugeeslo)
> >
> > Hopefully that is enough to identify the tests that are broken?
>
> I have now added code to skip the tests on FreeBSD wherever debuggeeslow
> is
> used. Unsure which test of the many is actually triggering it, but I have
> no
> time to invest on this either.
>
> So, is that acceptable for you for now?
>

That should be perfectly fine - thanks for skipping those tests on FreeBSD.

Please note that it is possible the issue also occurs on Linux however
we've no way of knowing if this is the case as the Docker containers are
used for one build only and then thrown away (which is also why it isn't an
issue there if it is happening, as the process of throwing away the
container will kill off any leftover processes)

Cheers,
Ben


> Cheers
>
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20210619/d471e439/attachment.htm>