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.
Ömer Fadıl Usta PGP key : 0xfd11561976b1690b about.me/omerusta Ben Cooksley <bcooks...@kde.org>, 16 Haz 2021 Çar, 21:57 tarihinde şunu yazdı: > On Thu, Jun 17, 2021 at 6:41 AM Nate Graham <n...@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 - because > 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 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. >> > >> > 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 why >> > 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 from >> > 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 >> >