On Fri, Aug 18, 2023, 12:53 PM Ben Cooksley <bcooks...@kde.org> wrote:
> On Sat, Aug 19, 2023 at 7:45 AM Nicolas Fella <nicolas.fe...@gmx.de> > wrote: > >> Am 18.08.23 um 21:41 schrieb Ben Cooksley: >> >> On Fri, Aug 18, 2023 at 10:17 PM Scarlett Moore < >> scarlett.gately.mo...@gmail.com> wrote: >> >>> >>> >>> On Fri, Aug 18, 2023, 12:55 AM Ben Cooksley <bcooks...@kde.org> wrote: >>> >>>> On Fri, Aug 18, 2023 at 3:53 AM Scarlett Moore < >>>> scarlett.gately.mo...@gmail.com> wrote: >>>> >>>>> Hello everyone, >>>>> >>>> >>>> Hey Scarlett, >>>> >>>> >>>>> I am asking to revisit per project repo snapcraft files. I see now >>>>> that flatpak files are in project repos but I understand this was >>>>> rejected for snapcraft. I would like to re-propose the idea, and here >>>>> is why. >>>>> The CI jobs for snap builds is cludgy at best. We have huge amounts of >>>>> failures because we must do a public upload to launchpad which places >>>>> us at the lowest priority and we have many timeouts etc. Their >>>>> solution is to create proper snap recipes pointing to our repos with >>>>> the snapcraft.yaml. Our current setup won't work because we use >>>>> subdirectories in one repo. >>>>> Thoughts? >>>>> >>>> >>>> My understanding (when automating the triggering of these builds on >>>> invent.kde.org was discussed with Sysadmin) was that the Snap folks >>>> had wanted to have everything in one repository. >>>> I had queried at the time why we weren't adding a file into each >>>> repository (which is what we do with Flatpak, and now with Craft as well - >>>> although those builds have yet to be widely rolled out) >>>> >>>> With regards to the triggering of these builds, how will this happen? >>>> It sounds like what you are describing here will result in Canonical >>>> servers polling invent.kde.org for changes, which is something we're >>>> not huge fans of as most projects only change every couple of days. >>>> >>>> >>>>> >>>>> Thanks for your time, >>>>> Scarlett >>>>> >>>> >>>> Cheers, >>>> Ben >>>> >>> >>> >>> Hi! >>> >>> Thanks all for responding. >>> >>> Albert: snapcraft files have been ironed out. I have been quite busy >>> over the last year doing so. >>> >>> Ben: There is an option to have launchpad build on changes which would >>> have polling. However, I would opt out of this feature and instead write >>> some tooling using launchpad API and Neons watcher tooling to update >>> versions and trigger launchpad builds. It would actually lighten the load >>> on KDE servers significantly. >>> >> >> Yes, we would definitely want to opt out of that completely - due to the >> number of repositories we have, any kind of polling quickly turns into a >> fairly significant number of requests. >> >> Wouldn't you want to trigger this from a .gitlab-ci.yml job definition >> though like we do for Flatpak and will be doing very soon for all of the >> Craft builds that support Android, Windows and Linux appimage binaries? >> >> I am definitely game for following a standard and do what everyone else is doing. Just point me to instructions and I will do it. Thanks! Scarlett > I was about to ask how the "future binary-factory" on invent will look >> like and suggest to follow that precedent. Can you elaborate on that? Will >> these be jobs in the relevant repos or will there be a meta-repo with all >> of the "release" jobs? >> > > The jobs will be sitting in the relevant repositories in a separate stage > to the current CI. > There will not be a meta repo for this. > > Individual applications for Craft will configure any extra behaviour they > need via a .craft.ini file at top level in the repository, on the branch in > question that the behaviour change is needed. > This is keeping in line with how our CI works (with .kde-ci.yml) and the > Flatpak builds work (with .flatpak-manifest.json/yml). > > Yet to be fully worked out how the triggering of them will be setup, > whether it will be automatic or whether it will be manually run but that is > an implementation detail. > > Cheers, > Ben >
