<div dir="ltr"><div>Probably the CI is testing for too many things.</div><div><br></div><div>I prefer to unit test on my own computer, and only the functions being affected.</div><div><br></div><div>CI may be useful for warranting that the overall program works, which catches almost every defect.</div><div><br></div><div>Exhaustive testing is useful when you are packaging the software for distribution, and you need to be 100% that all components integrate properly.</div><div><br></div><div>But testing everything for each small commit is wasteful.</div><div><br></div><div>Also your computer usually has more compute power available for compilation than a server in the cloud. Specially if the server is running multiple parallel jobs.</div><div><br></div><div>For reaching good quality is more important to be able to fix things quickly, and release those fixes, than having everything perfectly tested.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Feb 12, 2026 at 11:43 AM Vlad Zahorodnii <<a href="mailto:vlad.zahorodnii@kde.org">vlad.zahorodnii@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
CI congestion is a pretty painful problem at the moment. In the event of <br>
a version bump or a release, a lot of CI jobs can be created, which <br>
slows down CI significantly. Version bumps in Plasma, Gear, and so on <br>
can be felt everywhere. For example, if a merge request needs to run CI <br>
to get merged, it can take hours before it's merge request's turn to run <br>
its jobs.<br>
<br>
For that past 3 days, things have been really bad. A merge request could <br>
get stuck waiting for CI for 5-10 hours, some even timed out.<br>
<br>
The current CI experience is quite painful during such rush hours. It <br>
will be great if we could work something out. Maybe we could dynamically <br>
allocate additional CI runners when we know that CI is about to get <br>
really really busy? or perhaps implement some CI sharding scheme to <br>
contain heavy CI workloads like version bumps or mass rebuilds so other <br>
projects don't experience CI starvation?<br>
<br>
Regards,<br>
Vlad<br>
<br>
</blockquote></div>