Notice of withdrawal of CI services: KDevelop and KDE Connect

[Milian Wolff]

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.

> > 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?

Cheers

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20210617/771f4fcf/attachment.sig>