Notice of withdrawal of CI services: KDevelop and KDE Connect

[Ömer Fadıl USTA]

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 <bcooksley at kde.org>, 16 Haz 2021 Çar, 21:57 tarihinde şunu
yazdı:

> On Thu, Jun 17, 2021 at 6:41 AM Nate Graham <nate at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20210616/028040a9/attachment-0001.htm>