From kde-devel Thu Jun 17 09:25:15 2021 From: Ben Cooksley Date: Thu, 17 Jun 2021 09:25:15 +0000 To: kde-devel Subject: Re: Notice of withdrawal of CI services: KDevelop and KDE Connect Message-Id: X-MARC-Message: https://marc.info/?l=kde-devel&m=162392194613935 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--000000000000ad351d05c4f2c9d0" --000000000000ad351d05c4f2c9d0 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff 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. > > 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_debugeeslow (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_debugeeslow (debuggee_debugeeslo) Hopefully that is enough to identify the tests that are broken? > > Cheers and thanks for letting me know about this problem > > -- > Milian Wolff > mail@milianw.de > http://milianw.de Thanks, Ben --000000000000ad351d05c4f2c9d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 17, 2021 at 8:44 AM Milian Wo= lff <mail@milianw.de> wrote:
On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote:
> Hi all,=C2=A0
>
> 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 FreeBS= D
> cause gdb to hang and consume an entire CPU core indefinitely. This sl= ows
> down builds for all other projects using that CI server, and also prev= ents
> KWin tests from proceeding - completely blocking it's jobs. This f= ault is
> in the debuggee_slow family of tests.

Hey Ben,

Hi Milian,
=C2=A0

first time I hear of this issue. I simply don't have the capacity to tr= ack
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 Freen= ode meltdown) on a few occasions.=C2=A0
=C2=A0

That said: can we just disable it on the FreeBSD platform, if that's th= e only
one that exhibits this failure? Alternatively I'm obviously fine with s= kipping
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 + pla= tform
ifdef checks to skip it on freebsd.

I&#= 39;m afraid I only have records of the hung test processes (and the gdb pro= cesses above them using an entire CPU core indefinitely each).
jenkins =C2=A0 =C2=A060635 =C2=A0 0.0 =C2=A00.0 =C2=A0 12120 = =C2=A0 2256 =C2=A00 =C2=A0TXs+ 02:44 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0:00.00 /u= sr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 FreeBSDQt5.15/build/plu= gins/debuggercommon/tests/debuggees/debuggee_debugeeslow (debuggee_debugees= lo)
jenkins =C2=A0 =C2=A074167 =C2=A0 0.0 =C2=A00.0 =C2=A0 12120 =C2=A0 = 2260 =C2=A01 =C2=A0TXs+ 02:55 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0:00.00 /usr/home= /jenkins/workspace/KDevelop/kdevelop/kf5-qt5 FreeBSDQt5.15/build/plugins/de= buggercommon/tests/debuggees/debuggee_debugeeslow (debuggee_debugeeslo)
=

Hopefully that is enough to identify the tests th= at are broken?
=C2=A0

Cheers and thanks for letting me know about this problem

--
Milian Wolff
mail@milianw.de http://m= ilianw.de

Thanks,
Ben=C2=A0
--000000000000ad351d05c4f2c9d0--