On Sat, Aug 19, 2023 at 8:47 AM Scarlett Moore < scarlett.gately.mo...@gmail.com> wrote:
> > > 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 > >> >>> [Trim] Like many things, there are no written instructions as it were, however there are quite a few examples of how the other jobs are doing it. See https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/gitlab-templates for the existing templates we have for this. You'll see in the case of Flatpak and co that we're always referring to the sources in the current branch - ideally you will be able to do this with Snap as well. Only thing i'm confused about here is how having the file in the actual repo makes a difference from Canonical's end as you'll still be getting their systems to trigger the builds and presumably still getting the same set of failures? Thanks, Ben
