On Sat, Feb 14, 2026 at 2:36 AM Harald Sitter <[email protected]> wrote:
> On Fri, Feb 13, 2026 at 12:37 PM Ben Cooksley <[email protected]> wrote: > > Resource utilisation wise, i've not looked into whether there has been a > significant bump in the number of jobs, but over the past year some > additional CD support has been added so that indicates some trouble there. > > Going off on a tangent: if the resources aren't sufficient for the > development of our flagship products (ruqola is not one, nor is > messagelib, but also I don't know what either do without looking them > up so maybe they are crucial to something 🤷♂️) then we need to put > more resources up. > Which I already said I planned to do.... > > That said, I think the problem isn't one of resources so much as it is > one of scale 📈. From the repeat complaints about CI performance it > should be apparent that intermittently there are not enough resources. > That doesn't mean we need more resources in general, it means we need > the CI to be able to adapt and fan out into the cloud 🌫️ when there > is too much load for the persistent nodes. > Unfortunately CI nodes in order to perform well really need the half a terabyte of cached resources that the physical nodes carry - otherwise you end up having to spend time downloading multiple gigabytes of data for each job that starts. If you have a job that uses Appium, you need KWin. KWin for a Linux build is a 1GB artifact, ignoring everything it depends on. So moving into the cloud doesn't really work unfortunately as you'd spend more time downloading (which would strain the Gitlab master server) than actually building. Generally we only tend to get backlogged whenever: - PIM does a version bump (which they just need to stop doing and just let Gear release processes manage) - Gear/Plasma/Frameworks do a release - Nodes fall over and stop processing builds Replacing the existing nodes that are flaky with newer ones of similar processing capability (will be a couple of % slower), but which are more numerous in number, will likely alleviate the bulk of our issues, as more build slots should reduce the contention. > > HS > Cheers, Ben
