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",
>
> What can be done here to reestablish the old immediate continuous
> integration
> workflow? Where new APIs (also from KF) are instantly available?
>
> 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.
>
> So, how to solve those problems? Did I miss something?
> Could flatpak builds on master branches be made on-demand rather?
>

For the record, my rebuild of the 6.6-kf6preview Flatpak Runtime/SDK was
successful, and the failure that kicked this off in KUserFeedback has now
been fixed.
https://invent.kde.org/frameworks/kuserfeedback/-/jobs/1561435


> Cheers
> Friedrich
>
>
>
Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20240205/749d8223/attachment.htm>