[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Notice of withdrawal of CI services: KDevelop and KDE Connect
From: Ömer Fadıl USTA <omerusta () gmail ! com>
Date: 2021-06-16 19:05:32
Message-ID: CAATbBR1y6fL+PDpmU3bqb5444RBiL_kkgObVf3ZemUgWrfRynA () mail ! gmail ! com
[Download RAW message or body]
How about if we add a config flag for our ci machines and configure cmake
of these 2 project's test to ignore building/adding those problematic tests
whenever it saw those flags?
I don't know why but it doesn't sound correct to me to kill the ci build of
any project because of these types of problems.
=C3=96mer Fad=C4=B1l Usta
PGP key : 0xfd11561976b1690b
about.me/omerusta
Ben Cooksley <bcooksley@kde.org>, 16 Haz 2021 =C3=87ar, 21:57 tarihinde =C5=
=9Funu
yazd=C4=B1:
> On Thu, Jun 17, 2021 at 6:41 AM Nate Graham <nate@kde.org> wrote:
>
>> This kind of problem will be generically solved for everyone once we get
>> GitLab's pre-commit CI, which can block merging of MRs until the
>> failures are resolved--so they actually *will* be resolved. How soon can
>> we get that finally rolled out across KDE?
>>
>
> I'm afraid GitLab CI wouldn't have prevented this from occurring - becaus=
e
> the pre-merge CI still needs to run somewhere.
> The problem here is that the simple act of running the build
> degrades/breaks the builders for everyone else.
>
> In terms of a timeline on this, once I have the situation with Nextcloud
> sorted out (which had to be prioritised as the version we're on goes out =
of
> support in the next few months) we'll hopefully be able to work on GitLab
> CI (assuming another vendor of ours doesn't go and pull another major
> dependency bump stunt like Nextcloud did)
>
>
>> Until that happens, this sort of problem will recur infinitely because
>> people will continue to miss or ignore CI failures because they send
>> emails after merge/commit rather than before, and are formatted
>> semi-incomprehensibly.
>>
>> Nate
>>
>
> Regards,
> Ben
>
>
>>
>>
>> On 6/16/21 12:28 PM, 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 FreeBS=
D
>> > cause gdb to hang and consume an entire CPU core indefinitely. This
>> > slows down builds for all other projects using that CI server, and als=
o
>> > prevents KWin tests from proceeding - completely blocking it's jobs.
>> > This fault is in the debuggee_slow family of tests.
>> >
>> > As this issue has persisted for some time now despite being mentioned,
>> I
>> > require that the family of tests in question be disabled across all
>> > platforms.
>> >
>> > In the case of KDE Connect, as part of it's configure process it runs
>> an
>> > external command that results in dbus-daemon being launched. This
>> > process persists following the build and would only be cleaned up by
>> our
>> > tooling that runs tests. Should the compilation fail (as it does
>> > currently) it will result in the CI builder being broken - which is wh=
y
>> > we have had so many Windows builds fail lately.
>> >
>> > As this is an issue that has occurred previously, I require that the
>> > configure time check which is launching dbus-daemon to be expunged fro=
m
>> > KDE Connect.
>> >
>> > As a reminder to all projects, running commands that interact with
>> > dbus-daemon or kdeinit is not permitted during configure or build time=
.
>> >
>> > Regards,
>> > Ben Cooksley
>> > KDE Sysadmin
>>
>
[Attachment #3 (text/html)]
<div dir="ltr"><div>How about if we add a config flag for our ci machines and \
configure cmake of these 2 project's test to ignore building/adding those \
problematic tests whenever it saw those flags?</div><div>I don't know why but it \
doesn't sound correct to me to kill the ci build of any project because of these \
types of problems.<br></div><div><div><div dir="ltr" class="gmail_signature" \
data-smartmail="gmail_signature"><br>Ömer Fadıl Usta<br>PGP key : \
0xfd11561976b1690b<br><a href="http://about.me/omerusta" \
target="_blank">about.me/omerusta</a><br></div></div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">Ben Cooksley <<a \
href="mailto:bcooksley@kde.org">bcooksley@kde.org</a>>, 16 Haz 2021 Çar, 21:57 \
tarihinde şunu yazdı:<br></div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div dir="ltr">On Thu, Jun 17, 2021 at 6:41 AM Nate Graham <<a \
href="mailto:nate@kde.org" target="_blank">nate@kde.org</a>> wrote:<br></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This kind of problem \
will be generically solved for everyone once we get <br> GitLab's pre-commit CI, \
which can block merging of MRs until the <br> failures are resolved--so they actually \
*will* be resolved. How soon can <br> we get that finally rolled out across \
KDE?<br></blockquote><div><br></div><div>I'm afraid GitLab CI wouldn't have \
prevented this from occurring - because the pre-merge CI still needs to run \
somewhere.</div><div>The problem here is that the simple act of running the build \
degrades/breaks the builders for everyone else.</div><div><br></div><div>In terms of \
a timeline on this, once I have the situation with Nextcloud sorted out (which had to \
be prioritised as the version we're on goes out of support in the next few \
months) we'll hopefully be able to work on GitLab CI (assuming another vendor of \
ours doesn't go and pull another major dependency bump stunt like Nextcloud \
did)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
Until that happens, this sort of problem will recur infinitely because <br>
people will continue to miss or ignore CI failures because they send <br>
emails after merge/commit rather than before, and are formatted <br>
semi-incomprehensibly.<br>
<br>
Nate<br></blockquote><div><br></div><div>Regards,</div><div>Ben</div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> <br>
<br>
On 6/16/21 12:28 PM, Ben Cooksley wrote:<br>
> Hi all,<br>
> <br>
> The following is notice that I intend to withdraw CI services from the <br>
> following two KDE projects due to faults in their code or build system <br>
> which are having a significant adverse impact on the CI system and <br>
> negatively impacting on other projects:<br>
> <br>
> - KDevelop<br>
> - KDE Connect<br>
> <br>
> This withdrawal will be applied to all platforms.<br>
> <br>
> In the case of KDevelop, it has a series of unit tests which on FreeBSD <br>
> cause gdb to hang and consume an entire CPU core indefinitely. This <br>
> slows down builds for all other projects using that CI server, and also <br>
> prevents KWin tests from proceeding - completely blocking it's jobs. <br>
> This fault is in the debuggee_slow family of tests.<br>
> <br>
> As this issue has persisted for some time now despite being mentioned, I <br>
> require that the family of tests in question be disabled across all <br>
> platforms.<br>
> <br>
> In the case of KDE Connect, as part of it's configure process it runs an \
<br> > external command that results in dbus-daemon being launched. This <br>
> process persists following the build and would only be cleaned up by our <br>
> tooling that runs tests. Should the compilation fail (as it does <br>
> currently) it will result in the CI builder being broken - which is why <br>
> we have had so many Windows builds fail lately.<br>
> <br>
> As this is an issue that has occurred previously, I require that the <br>
> configure time check which is launching dbus-daemon to be expunged from <br>
> KDE Connect.<br>
> <br>
> As a reminder to all projects, running commands that interact with <br>
> dbus-daemon or kdeinit is not permitted during configure or build time.<br>
> <br>
> Regards,<br>
> Ben Cooksley<br>
> KDE Sysadmin<br>
</blockquote></div></div>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic