CI Flatpak Builds

[Ben Cooksley]

On Sat, Jan 25, 2025 at 10:46 AM Ingo Klöcker <kloecker at kde.org> wrote:

> On Freitag, 24. Januar 2025 18:57:43 Mitteleuropäische Normalzeit Ben
> Cooksley
> wrote:
> > I had been thinking that having a separate file that would be used
> instead
> > of .flatpak-manifest.yml if present when doing a build on a stable branch
> > would be a good solution.
> > Under this you would have a .flatpak-manifest.yml and a
> > .flatpak-manifest-stable.yml file
> >
> > When building on master the .flatpak-manifest.yml file would be used, but
> > when on a release branch / tag the .flatpak-manifest-stable.yml file
> would
> > be used instead (if present).
> >
> > That would eliminate needing the release manager / developer to update
> > .flatpak-manifest.yml on branching a new stable release branch.
>
> Doesn't that mean that the .flatpak-manifest-stable.yml file would be
> completely
> untested until the branching happens? We all know what happens if things
> are
> not tested on a regular basis.
>

Yes, unfortunately this is one of those issues where we are going to lose
either way.
You can either ensure your builds are reproducible and able to be
replicated in the future by someone, or decide to chase upstream to ensure
they haven't broken things and pulled the rug out from underneath you.

Both approaches have their pros and cons however we should understand that
if we opt to chase upstream then our ability to produce CD builds that are
suitable for end user distribution will be impaired.

In this instance we need to make a decision as to whether the Flatpak build
is intended to be a CD build suitable for end-user distribution, or are we
actually using it as another form of CI.
When it was introduced it was intended as a form of CD build.

I'll note that we should probably also tighten up how we handle our
relationships with upstreams that break things too often and (strongly)
encourage them to not break things.


>
> Regards,
> Ingo
>

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20250125/9aaf11b0/attachment-0001.htm>