CI Utilisation and system efficiency

[Ben Cooksley]

On Sat, Apr 19, 2025 at 8:07 PM Vlad Zahorodnii <vlad.zahorodnii at kde.org>
wrote:

> On 4/19/25 10:53 AM, Kai Uwe Broulik wrote:
> > Hi,
> >
> > thanks for looking into this.
> >
> > It seems a major contributor to CI time is the fact that a merge
> > request runs and once merged, master runs another pretty much
> > identical pipeline right after that.
>

A big part of the issue here is our rebase centric workflow - normally with
Gitlab you use merge commits and in this workflow CI only runs when the MR
changes.
With a rebase workflow like ours though, other changes to the repo require
the merge request to be updated - triggering unnecessary CI runs.

Note that builds on master are absolutely critical - both for applications
making use of CD builds, and for general applications - because only master
(and release branches) are marked as "protected".
Binary signing for CD builds as well as publishing of build artifacts for
other CI jobs to reuse only happens on protected branches - as these are
sensitive.

>
> > As for KWin: Not sure which one we could axe. KWin uses a bunch of
> > internal Qt stuff, so catching Qt dev regressions/private API changes
> > early is important.
>

I already mentioned how you have three Linux jobs: Qt 6.9, Qt 6.9 Feature
Set Reduced and Qt 6.10.
Given all the weird things KWin does you have to keep Qt 6.10, which makes
it a choice between the two Qt 6.9 jobs.

As Qt 6.9 is in general covered by Feature Set Reduced you should drop that
one as it provides additional value over what Qt 6.10 offers by ensuring
the minimal build still compiles.
There will be a small gap of code outside the scope of Feature Set Reduced
being exposed to potential build regressions but that is something you'll
be guarded against by at least some developers using Qt 6.9 locally.

Otherwise you can declare the Feature Set Reduced build unsupported and
remove it.


>
> Not sure what we can do about kwin. I looked how we can reduce the time
> needed to run tests, and there's not much space for improvements

anymore. Speaking for kwin, I personally wouldn't mind if KDE adopts a
> different policy regarding running CI. For example, only run CI when
> it's time to merge a change and after a change lands in master or if a
> pipeline is manually triggered by a developer.
>

Gitlab doesn't support what you are describing i'm afraid - there is no way
of telling it "i'm ready to merge this change now".
Realistically merge requests shouldn't be proposed until people are ready
to get something reviewed and merged in...


>
> Regards,
> Vlad
>
>
Regards,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20250419/acefb7ab/attachment-0001.htm>