Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches

[Julius Künzel]

> Besides all the resource costs to create flatpaks on master builds by default
every time, when those are usually not used by anyone anyway.

It is important to mention that the pipelines on master usually publish to the nightly repos on cdn.kde.org/flatpak I guess you were not aware of that otherwise I wonder what makes you so confident to know nobody uses it?

Cheers,
Julius

04.02.2024 19:23:06 Ben Cooksley <bcooksley at kde.org>:

> On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
>> Hi,
>> 
>> ((cc:kde-frameworks-devel for heads-up, replies please only to kde-core-deve))
>> 
>> 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.
>> 
>> 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,
>> but some older (anywhere documented?) snapshot:
>> 
>>     "runtime-version": "6.6-kf6preview",
> 
> Please see https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6 for what is in the KF6 preview.
>  
>> 
>> What can be done here to reestablish the old immediate continuous integration
>> workflow? Where new APIs (also from KF) are instantly available?
> 
> 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.
>  
>> 
>> 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.
>> 
>> Blocking latest KF API from usage also means less testing of that before the
>> initial release. 
>> 
>> Besides all the resource costs to create flatpaks on master builds by default
>> every time, when those are usually not used by anyone anyway.
> 
> 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.
> 
> There are ways (in .craft.ini) to make newer Frameworks available, but that requires that the system recompiles that Framework each time you trigger a build and is therefore not recommended.
>  
> Allowing those systems to use the "latest" artifacts of Frameworks would be a non-trivial exercise.
> 
>> 
>> So, how to solve those problems? Did I miss something?
>> Could flatpak builds on master branches be made on-demand rather?
>> 
>> Cheers
>> Friedrich
> 
> Cheers,
> Ben 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20240205/9ba06d58/attachment-0001.htm>