Probably the CI is testing for too many things. I prefer to unit test on my own computer, and only the functions being affected.
CI may be useful for warranting that the overall program works, which catches almost every defect. Exhaustive testing is useful when you are packaging the software for distribution, and you need to be 100% that all components integrate properly. But testing everything for each small commit is wasteful. 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. For reaching good quality is more important to be able to fix things quickly, and release those fixes, than having everything perfectly tested. On Thu, Feb 12, 2026 at 11:43 AM Vlad Zahorodnii <[email protected]> wrote: > Hello, > > CI congestion is a pretty painful problem at the moment. In the event of > a version bump or a release, a lot of CI jobs can be created, which > slows down CI significantly. Version bumps in Plasma, Gear, and so on > can be felt everywhere. For example, if a merge request needs to run CI > to get merged, it can take hours before it's merge request's turn to run > its jobs. > > For that past 3 days, things have been really bad. A merge request could > get stuck waiting for CI for 5-10 hours, some even timed out. > > The current CI experience is quite painful during such rush hours. It > will be great if we could work something out. Maybe we could dynamically > allocate additional CI runners when we know that CI is about to get > really really busy? or perhaps implement some CI sharding scheme to > contain heavy CI workloads like version bumps or mass rebuilds so other > projects don't experience CI starvation? > > Regards, > Vlad > >
