On Wed, Sep 20, 2023 at 9:42 AM Albert Astals Cid <aa...@kde.org> wrote:
> El dimarts, 19 de setembre de 2023, a les 22:18:40 (CEST), > christ...@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 > The overall intention is for the bundles produced by the Flatpak jobs to be useful for people to locally test a project build. In the not too distant future we'll have them available from a Flatpak repository for actual mainline/release branches as well. So the answer certainly isn't (a). > > 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. > Guess it depends on the nature of the dependency, but in the case of software released together you probably want to build against what you will be shipping against yes. > > 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. > This is my preferred solution as well. it wouldn't be too difficult given we have a Python script acting as a middle-man already. In the past we did some rewriting of the .flatpak-manifest.yml already. Depending on our requirements it may be worth tying into the same branch-rules.yml logic that the rest of the CI system uses but this is probably best answered by someone who knows the various Flatpak manifests we have better. In #flatpak:kde.org it was mentioned that this would mean that people wouldn't be able to build it as easily themselves, but if we make it well documented (comments in the .flatpak-manifest.yml, etc) then I think this shouldn't be much of an issue. > > D) Something smarter I have not thought about. > > Cheers, > Albert > Cheers, Ben > > > > > 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 > > > > >
