flatpak CI and stable builds - Re: KDE Gear projects with failing CI (release/23.08) (12 September 2023)

[Albert Astals Cid]

El dimarts, 19 de setembre de 2023, a les 22:18:40 (CEST), 
christoph at cullmann.io va escriure:
> On 2023-09-19 21:35, Albert Astals Cid wrote:
> > Please work on fixing them, otherwise i will remove the failing CI
> > jobs on their 4th failing week, it is very important that CI is passing
> > for
> > multiple reasons.
> > 
> > Bad news: We have 2 new repositories failing :/
> > 
> > = FLATPAK FAILING =
> > 
> > kate:
> >  * https://invent.kde.org/utilities/kate/-/pipelines/484147
> >  
> >   * This highlights a design problem, it's building markdown part from
> > 
> > master
> > instead of from stable branch. We can manually change the branch, but i
> > would
> > prefer a solution that doesn't mean changing lots and lots of flatpak
> > manifests when we branch.
> 
> Hmm, yes that sounds not nice.
> 
> But not sure how that would work without that, seems
> 
> https://invent.kde.org/utilities/kate/-/blob/master/.flatpak-manifest.json?r
> ef_type=heads
> 
> hard codes what to fetch.
> 
> Given one hard codes there the
> 
>   "runtime-version": "5.15-22.08",

That one is "fine", the 22.08 here it's related to the "flatpak kde/
freedesktop sdk" not to Gear stuff.

Yes, we will massively have to update them on master when we decide to depend 
on a new one, but it won't cause problems on the stable branches like the oner 
we're experiencing here.

The problem here is 

{
  "name": "markdownpart",
  "buildsystem": "cmake-ninja",
  "sources": [
    {
      "type": "git",
      "url": "https://invent.kde.org/utilities/markdownpart.git"
    }
  ]
}

This unconditionally compiles the master branch of markdownpart repo

As far as i can see there's three solutions:

A) If this is just "to make sure it builds CI", we don't need markdownpart nor 
konsole on the flatpak since they are just runtime dependencies. This is a 
sub-optimal solution i'd say since it makes it so that we can't offer the 
package for testing in the future and makes the diff with the flathub manifest 
bigger than it needs to be

B) Depend on released versions, i.e. a tarball in "sources" instead of a git 
repo. This is probably suboptimal too in the sense that will require constant 
updating on master and if we offer the resulting flatpak as "nightly" in the 
future for testing it's not "nightly" as it could be.

C) Add a marker in the .json like branch: "kde-same-branch" and then have the 
code in https://invent.kde.org/sysadmin/ci-utilities/raw/master/gitlab-templates/flatpak.yml replace that "kde-same-branch" either by "master" or by 
the appropriate stable branch before actually compiling the flatpak. I think 
this would be the optimal solution but needs work.

D) Something smarter I have not thought about.

Cheers,
  Albert

> 
> I assume one will need to hard code that, too, if one creates no own
> scripting.
> 
> But I might be wrong.
> 
> Greetings
> Christoph
> 
> > = FAILING UNIT TESTS =
> > 
> > konsole:
> >  * https://invent.kde.org/utilities/konsole/-/pipelines/484148
> >  
> >   * freebsd_qt515 tests are failing