[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: Julius_Künzel <jk.kdedev () smartlab ! uber ! space>
Date: 2024-02-04 23:15:00
Message-ID: 5ac5305a-b8de-418c-9e8c-87d28338a3f9 () smartlab ! uber ! space
[Download RAW message or body]
> 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@kde.org>:
> 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)]
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
<span dir="ltr" style="margin-top:0; margin-bottom:0;">> Besides all the \
resource costs to create flatpaks on master builds by default</span> <br><span \
dir="ltr" style="margin-top:0; margin-bottom:0;">every time, when those are usually \
not used by anyone anyway.</span> <br>
<br><span dir="ltr" style="margin-top:0; margin-bottom:0;">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?</span> <br>
<br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Cheers,</span>
<br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Julius</span>
<br>
<div>
<div dir="ltr">
<p>04.02.2024 19:23:06 Ben Cooksley <bcooksley@kde.org>:</p>
</div>
<blockquote style="margin:0;border-left:3px solid #ccc; padding-left:10px;">
<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>
</blockquote>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic