<div dir="ltr"><div dir="ltr">On Sat, Apr 19, 2025 at 8:07 PM Vlad Zahorodnii <<a href="mailto:vlad.zahorodnii@kde.org">vlad.zahorodnii@kde.org</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/19/25 10:53 AM, Kai Uwe Broulik wrote:<br>
> Hi,<br>
><br>
> thanks for looking into this.<br>
><br>
> It seems a major contributor to CI time is the fact that a merge <br>
> request runs and once merged, master runs another pretty much <br>
> identical pipeline right after that.<br></blockquote><div><br></div><div><div>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.</div><div>With a rebase workflow like ours though, other changes to the repo require the merge request to be updated - triggering unnecessary CI runs.</div><div><br></div></div><div>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".</div><div>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.</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>
> As for KWin: Not sure which one we could axe. KWin uses a bunch of <br>
> internal Qt stuff, so catching Qt dev regressions/private API changes <br>
> early is important.<br></blockquote><div><br></div><div>I already mentioned how you have three Linux jobs: Qt 6.9, Qt 6.9 Feature Set Reduced and Qt 6.10.</div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>Otherwise you can declare the Feature Set Reduced build unsupported and remove it.</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>
Not sure what we can do about kwin. I looked how we can reduce the time <br>
needed to run tests, and there's not much space for improvements</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
anymore. Speaking for kwin, I personally wouldn't mind if KDE adopts a <br>
different policy regarding running CI. For example, only run CI when <br>
it's time to merge a change and after a change lands in master or if a <br>
pipeline is manually triggered by a developer.<br></blockquote><div><br></div><div>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".</div><div>Realistically merge requests shouldn't be proposed until people are ready to get something reviewed and merged in...</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>
Regards,<br>
Vlad<br>
<br></blockquote><div><br></div><div>Regards,</div><div>Ben </div></div></div>