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

[Ben Cooksley]

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-windows/attachments/20240205/ac68607a/attachment.htm>