CI Flatpak Builds

[Justin Zobel]

On 24/1/25 02:55, Volker Krause wrote:
> On Donnerstag, 23. Januar 2025 10:21:08 Mitteleuropäische Normalzeit Ben
> Cooksley wrote:
>> On Thu, Jan 23, 2025 at 7:21 AM Volker Krause <vkrause at kde.org> wrote:
>>> On Mittwoch, 22. Januar 2025 18:52:46 Mitteleuropäische Normalzeit Ben
>>>
>>> Cooksley wrote:
>>>> On Thu, Jan 23, 2025 at 5:49 AM Volker Krause <vkrause at kde.org> wrote:
>>>>> On Dienstag, 21. Januar 2025 23:11:56 Mitteleuropäische Normalzeit
>>> Albert
>>>
>>>>> Astals Cid wrote:
>>>>>> neochat - NEW
>>>>>>
>>>>>>   * https://invent.kde.org/network/neochat/-/pipelines/869365
>>>>>>   
>>>>>>    * flatpak build fails
>>>>> Same as https://invent.kde.org/network/neochat/-/merge_requests/2127 I
>>>>> guess,
>>>>> looks like an API change in libQuotient with the corresponding version
>>>>> change
>>>>> still pending (ie. a similar problem we occasionally hit with
>>>>> Poppler).
>>>>>
>>>>> The quick solution for this would probably be (temporarily) switching
>>>>> Flatpak
>>>>> to the latest release of libQuotient. The IMHO proper solution would
>>> be to
>>>
>>>>> have version bumps at the beginning of a development cycle that
>>>>> changes
>>>>> API.
>>>> This also raises another question though - should we be strongly
>>>> discouraging use of heavily moving targets like upstream dev / master
>>>> branches and instead favouring the use of stable branches?
>>>> Not really ideal if upstream can essentially break our builds without us
>>>> doing anything.
>>> I can't comment on NeoChat, but for Itinerary the builds against the
>>> latest
>>> versions of essential (external) dependencies with varying
>>> intentions/success
>>> in keeping backward compatibility (ZXing, Poppler, Quotient) are very much
>>> deliberate, to catch breakage/regressions early (same as we are now doing
>>> for
>>> KF with Qt pre-releases).
>>>
>>> And this is actually working, NeoChat has been fixed to build with the
>>> upcoming
>>> Quotient version, same for Itinerary/Poppler. The only thing we are
>>> missing
>>> for those fixes to take effect is those dependencies bumping their version
>>> numbers.
>>>
>>> We could work around that by doing configure-time detection using a
>>> compile
>>> test, but that's a lot of extra work, so we'd better try to address this
>>> upstream first.
>>>
>>>
>>> I'd very much suggest the use of release tarballs (or stable branches) for
>>> apps that aren't continuously monitoring their dependencies this way
>>> though,
>>> but I'm not aware we have such a case.
>> Doesn't this interfere somewhat with the long term eventual goal of us
>> pushing Flatpak binaries directly to Flathub though?
>> (not to mention make stable branch builds impossible to reproduce in the
>> long run)
> For Itinerary at least the release branch is using release tarballs rather
> than (latest) Git branches, matching what we have on Flathub. (This does imply
> some manual work at branch time, but at least for me that's more than offset by
> what this saves in catching issues early).
>
> But you are right of course that this is abusing Flatpak a bit as CI. That's
> not ideal but it's just very tempting as it has minimal extra cost (Flatpak
> has to build those dependencies anyway, and Flatpak builds run less often than
> normal CI builds).
>
> Regards,
> Volker

I've moved this to a new email subject as it's no longer just about 
failing CI builds.

My proposal would be have 3 files in the repository that are Flatpak 
related:

- .flatpak-manifest.yml will continue to exist for git master builds and 
be deployed to https://cdn.kde.org/flatpak/

- org.kde.appname.json which will be for Flathub stable builds will only 
run on release branches when a tag is made (I am hoping CI can be 
triggered by a tag).

- Both will reference a file called org.kde.appname.dependencies.json 
which contains the the dependencies that get build for the app and will 
point to tarballs or tags for released versions.

Flatpak supports referencing external files for build dependencies and 
you can use JSON or YAML interchangeably.

I think this will be good for Flatpak builds as we really want them 
targeting the stable released tarballs, not some function in git master 
of a dependency that *MIGHT* be released in time for the next KDE release.