On Tue, May 6, 2025 at 5:36 AM Volker Krause <vkra...@kde.org> wrote:
> On Freitag, 2. Mai 2025 22:55:34 Mitteleuropäische Sommerzeit Ben Cooksley > wrote: > > On Sat, May 3, 2025 at 8:26 AM Christoph Cullmann <christ...@cullmann.io > > > > > > wrote: > > > On Friday, May 2nd, 2025 at 22:18, Ben Cooksley <bcooks...@kde.org> > wrote: > > > > > > On Sat, May 3, 2025 at 3:27 AM Christoph Cullmann < > christ...@cullmann.io> > > > > > > wrote: > > >> Hi, > > >> > > >> at work we use cmake unity build to save time & costs. > > >> > > >> Would that be some idea here, too? > > >> > > >> Naturally as side effect that can hide compile issues > > >> or introduce ones. > > > > > > We could look into that, just not sure how it would save compile times > > > though? > > > We have extremely fast NVMe storage on the builders, so we're unlikely > to > > > be IO constrained. > > > > > > > > > Hi, > > > > > > that saves more compute power than IO, you parse headers just 1/x of > the > > > time for x sized units > > > and you spawn just 1/x of the processes, at work, that leads to 2 or 4 > > > times the speed, on bare metal > > > machines with only SSDs, too. > > > > > > But naturally that will depend on the projects. > > > > I see. Based on the CMake documentation it sounds like something that > > doesn't always work so i'm hesitant to enable it as a global flag. > > The CI system through the option cmake-options in .kde-ci.yml can allow > for > > the necessary unity build flags to be passed - so this is something heavy > > users with lots of files may want to look into. > > Right, this is probably not a suitable default. > > What might be worth exploring though is using unity builds for QML > cachegen > code by default. That's many somewhat uniform and predictable files with > the > same includes etc. And at least for several things in the top 20 those > files > are a significant part of the cost. > This sounds like something that needs to be sorted within ECM / Frameworks / the applications themselves though and isn't something that can be done at a global CI level? > > Regards, > Volker > Cheers, Ben > > > >> On Friday, April 18th, 2025 at 21:25, Ben Cooksley <bcooks...@kde.org > > > > >> wrote: > > >> > > >> Hi all, > > >> > > >> Over the past week or two there have been a number of complaints > > >> regarding CI builder availability which i've done some investigating > into > > >> this morning. > > >> > > >> Part of this is related to the Windows CI builders falling offline > due to > > >> OOM events, however the rest is simply due to a lack of builder time > > >> availability (which is what this email is focused on). > > >> > > >> Given we have 6 Hetzner AX51 servers connected to Gitlab (each > equipped > > >> with a Ryzen 7 7700 CPU, 64GB RAM and NVMe storage) the issue is not > > >> available build power - it is the number of builds and the length of > > >> those > > >> builds that is at issue. > > >> > > >> This morning I ran a basic query to ascertain the top 20 projects for > CI > > >> time utilisation on invent.kde.org which revealed the following: > > >> > > >> full_path | time_used | job_count > > >> ------------------------------+------------------+----------- > > >> plasma/kwin | 320:47:04.966412 | 2387 > > >> graphics/krita | 178:03:19.080763 | 423 > > >> multimedia/kdenlive | 174:08:09.876842 | 697 > > >> network/ruqola | 173:17:47.311305 | 555 > > >> plasma/plasma-workspace | 155:10:03.618929 | 660 > > >> network/neochat | 138:03:23.926652 | 1546 > > >> education/kstars | 129:49:17.74229 | 329 > > >> sysadmin/ci-management | 111:21:09.739792 | 154 > > >> plasma/plasma-desktop | 108:56:52.849433 | 776 > > >> kde-linux/kde-linux-packages | 81:00:10.001937 | 33 > > >> kdevelop/kdevelop | 59:40:51.54474 | 217 > > >> office/kmymoney | 54:32:00.24623 | 271 > > >> frameworks/kio | 53:54:19.046685 | 690 > > >> education/labplot | 52:36:30.343671 | 245 > > >> murveit/kstars | 52:32:56.882728 | 128 > > >> frameworks/kirigami | 47:07:19.172935 | 1627 > > >> system/dolphin | 46:09:58.02836 | 705 > > >> kde-linux/kde-linux | 39:25:54.052469 | 46 > > >> utilities/kate | 36:09:22.18958 | 356 > > >> wreissenberger/kstars | 35:58:14.120515 | 105 > > >> > > >> If we look closely, KStars has three spots on this list (totalling 216 > > >> hours of time used, making it the biggest app user of CI time). > > >> > > >> Projects on the above list are asked to please review their jobs and > how > > >> they are conducting development to ensure CI time is used efficiently > and > > >> appropriately. > > >> > > >> Other projects should also please review their usage and optimise > > >> accordingly even if they're not on this list as there is efficiencies > to > > >> be > > >> found in all projects. > > >> > > >> When reviewing the list of CI builds projects have enabled, it is > > >> important to consider to what degree your project benefits from having > > >> various builds enabled. One common pattern i've seen is having Alpine, > > >> SUSE > > >> Qt 6.9 and SUSE Qt 6.10 all enabled. > > >> > > >> If you need to verify building on Alpine / MUSL type systems and wish > to > > >> monitor for Qt Next regressions then you probably shouldn't have a > > >> conventional Linux Qt stable build as those two jobs between them > already > > >> cover that list of permutations. > > >> > > >> I've taken a quick look at some of these and can suggest the > following: > > >> > > >> KWin: it has two conventional Linux jobs (suse_qt69 and suse_qt610) > plus > > >> a custom reduced feature set job. It seems like one of these > conventional > > >> Linux jobs should be dropped. > > >> > > >> KStars: Appears to have a custom Linux job in addition to a > conventional > > >> Linux job. Choose one please. > > >> > > >> Ruqola: Appears to be conducting a development process whereby changes > > >> are made in stable then immediately merged to master in a ever > continuing > > >> loop. Please discontinue this behaviour and only periodically merge > > >> stable > > >> to master. > > >> > > >> Also needs to drop one of it's Linux jobs as they're duplicating > > >> functionality as noted above. > > >> > > >> Plasma Workspace/Desktop: At least in part this seems to be driven by > > >> Appium tests. Please reduce the number of these and/or streamline the > > >> process for running an Appium test. Consideration should be given to > > >> enabling the CI option use-ccache as well. > > >> > > >> KDevelop: Please enable the CI option use-ccache. > > >> > > >> Labplot: Appears to have a strange customisation in place to the > standard > > >> jobs which shouldn't be necessary as flags in .kde-ci.yml should > permit > > >> that to be done. > > >> > > >> Thanks, > > >> Ben > >
