[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-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-05 9:58:07
Message-ID: CA+XidOGq8S+WaShRwbLSA+yGu+dZTVWpEhfHCz+Ff++dRe0sYQ () 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",
>
> 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

[Attachment #3 (text/html)]

<div dir="ltr"><div dir="ltr">On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. \
Kossebau &lt;<a href="mailto:kossebau@kde.org">kossebau@kde.org</a>&gt; \
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>
      &quot;runtime-version&quot;: &quot;6.6-kf6preview&quot;,<br>
<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>
<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.<br>
<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>
<br>
So, how to solve those problems? Did I miss something?<br>
Could flatpak builds on master branches be made on-demand \
rather?<br></blockquote><div><br></div><div>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.</div><div><a \
href="https://invent.kde.org/frameworks/kuserfeedback/-/jobs/1561435">https://invent.k \
de.org/frameworks/kuserfeedback/-/jobs/1561435</a><br></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>
Cheers<br>
Friedrich<br>
<br>
<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]