[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
From: Ben Cooksley <bcooksley () kde ! org>
Date: 2024-02-04 18:22:28
Message-ID: CA+XidOEVzKVVAP6Q173YZrhvo78WUdQ9TzHCDfSmm4rXn0guzA () mail ! gmail ! com
[Download RAW message or body]
On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau <kossebau@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
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr">On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. \
Kossebau <<a href="mailto:kossebau@kde.org" \
target="_blank">kossebau@kde.org</a>> wrote:<br></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br>
((cc:kde-frameworks-devel for heads-up, replies please only to kde-core-deve))<br>
<br>
I hit the problem that when working on a repo which would like to use latest <br>
KF development state to integrate some new KF API just added in cooperation <br>
with that very repo wanting to use it, I cannot do so when someone had added a <br>
flatpak job on CI to that repo.<br>
<br>
Because with such flatpak jobs it seems they are limiting the available KF <br>
version not to the current latest one, as expected for continuous integration, <br>
but some older (anywhere documented?) snapshot:<br>
<br>
"runtime-version": \
"6.6-kf6preview",<br></blockquote><div><br></div><div>Please see <a \
href="https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6">https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6</a> \
for what is in the KF6 preview.</div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
What can be done here to reestablish the old immediate continuous integration <br>
workflow? Where new APIs (also from KF) are instantly \
available?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
Right now this is a new extra burden which makes working on new features with <br>
KF and apps more complicated. Thus less interesting, and one/I would rather <br>
duplicate code in apps to get things done.<br>
<br>
Blocking latest KF API from usage also means less testing of that before the <br>
initial release. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
Besides all the resource costs to create flatpaks on master builds by default <br>
every time, when those are usually not used by anyone \
anyway.<br></blockquote><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div> \
</div><div>Allowing those systems to use the "latest" artifacts of \
Frameworks would be a non-trivial exercise.</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
So, how to solve those problems? Did I miss something?<br>
Could flatpak builds on master branches be made on-demand \
rather?</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
Cheers<br>
Friedrich<br></blockquote><div><br></div><div>Cheers,</div><div>Ben \
</div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic