<div dir="ltr"><div dir="ltr">On Thu, Jun 17, 2021 at 6:41 AM Nate Graham <<a href="mailto:nate@kde.org">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>