From kde-core-devel Wed Feb 07 18:48:27 2024 From: "Friedrich W. H. Kossebau" Date: Wed, 07 Feb 2024 18:48:27 +0000 To: kde-core-devel Subject: Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches Message-Id: <2390005.cojqenx9y0 () klux> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=170733167610805 Am Sonntag, 4. Februar 2024, 19:22:28 CET schrieb Ben Cooksley: > On Mon, Feb 5, 2024 at 4:28=E2=80=AFAM Friedrich W. H. Kossebau >=20 > wrote: > > Hi, > >=20 > > ((cc:kde-frameworks-devel for heads-up, replies please only to > > kde-core-deve)) > >=20 > > I hit the problem that when working on a repo which would like to use > > latest > > KF development state to integrate some new KF API just added in > > cooperation > > with that very repo wanting to use it, I cannot do so when someone had > > added a > > flatpak job on CI to that repo. > >=20 > > Because with such flatpak jobs it seems they are limiting the available= KF > > version not to the current latest one, as expected for continuous > > integration, > >=20 > > but some older (anywhere documented?) snapshot: > > "runtime-version": "6.6-kf6preview", >=20 > Please see https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6 > for what is in the KF6 preview. Thanks. So documented by implementation :) > > What can be done here to reestablish the old immediate continuous > > integration > > workflow? Where new APIs (also from KF) are instantly available? >=20 > With Flatpak new APIs were never instantly available - there has always > been a delay as the Flatpak Runtime uses the most recent released version > of our software. I guess this was shadowed by feature development of KF having stalled durin= g=20 the Qt5/KF5->Qt6/KG6 porting phase as well as Qt6-based flatpaks jobs only= =20 activated recently. > > Right now this is a new extra burden which makes working on new features > > with > > KF and apps more complicated. Thus less interesting, and one/I would > > rather > > duplicate code in apps to get things done. > >=20 > > Blocking latest KF API from usage also means less testing of that before > > the > > initial release. > >=20 > >=20 > > Besides all the resource costs to create flatpaks on master builds by > > default > > every time, when those are usually not used by anyone anyway. >=20 > Those applications that have a hard dependency on features being added to > Frameworks are not good candidates for making use of our Continuous > Delivery systems i'm afraid. > Both Flatpak and Craft based (Linux Appimages, Android APKs, Windows and > macOS) CD jobs are best optimised for those applications that rely on the > stable Frameworks releases. >=20 > There are ways (in .craft.ini) to make newer Frameworks available, but th= at > requires that the system recompiles that Framework each time you trigger a > build and is therefore not recommended. >=20 > Allowing those systems to use the "latest" artifacts of Frameworks would = be > a non-trivial exercise. So effectively this means: * KF - no CI on new API with non-KF repos, only KF-internal CI * KF - no CD, only released versions Which makes KF a second class product, with lesser testing :( And less interesting to contribute to, given it gets worse CI/CD care. One challenge I face myself here are community maintained products, like KD= E=20 games. I have had some pleasure in spending some time recently (well, a lot= =20 actually) on them to make sure they all properly move to Q6/KF6 for Gear=20 24.02. And would assess myself success here. Now others have on their own enabled flatpak builds for all the repos on th= e=20 master branch. Because they "could" and it worked at that moment in time wi= th=20 the dependencies. I have some experimental work for the games collected during the Qt6/KF6 po= rt=20 work which still needs some brush up & further tuning. It would require=20 changes to KF, libkdegames & then all the games. The current setup which seems to defaults to "binary builds everywhere" mak= es=20 completing that work now something which seems to go against current standa= rds=20 and makes me feel uncomfortable, as if I do something wrong/against the pla= ns,=20 as I would have to disable all the flatpak builds. (Besides having to do al= l=20 the care/extra work here for an ecosystem I have no business with). =46or me this is an extra hurdle to work in KDE. And things are made worse = for=20 me given I am not convinced by those platforms (besides AppImage perhaps)=20 which now are ruling contribution/development here.=20 I understand people fancy easy deployment on their favourite platforms, so = do=20 I. There was a time when also Debian package info was in some KDE projects= =20 IIRC. But please think about those who are not into your respective platform, do= =20 not force them into (supporting) yours. > > So, how to solve those problems? Did I miss something? > > Could flatpak builds on master branches be made on-demand rather? Cheers =46riedrich